Uploaded image for project: 'CDI Specification Issues'
  1. CDI Specification Issues
  2. CDI-30

An API for managing built in contexts designed for other frameworks

    Details

    • Type: Feature Request
    • Status: Pull Request Sent (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0
    • Fix Version/s: 2.0 (discussion)
    • Component/s: Contexts
    • Labels:
      None

      Description

      In order to allow CDI to play well in the general ecosystem, it needs to have SPIs. These SPIs need to allow other libraries to do things like register beans (CDI extensions), look up a bean manager, and get managed versions of its classes.

      CDI has no way currently to support a framework starting and stopping built in contexts. These built in contexts are not really clear in how they are started, other than the container is responsible for starting them. This means its near impossible for an external library which is not Java EE aware to start these built in contexts. Being able to reuse these contexts allow developers to build their beans once and reuse them in many use cases.

      These use cases may include:

      1. Quartz Scheduler/CDI Integration. A Prototype of this is available in DeltaSpike, where jobs can be managed beans, by overriding the InstanceJobFactory, and can have contexts started via an annotation. To bring it a step further, Quartz, in order to mirror Java EE capabilities, may want to say that during the execution of a job, an instance of a request context is active. To do this, the developer should not need to do anything, but instead Quartz may automatically register a job listener that starts and stops the context (see: http://www.quartz-scheduler.org/documentation/quartz-2.2.x/cookbook/JobListeners.html)

      2. Camel-CDI. Camel may want to say that during the execution of a route, a request context is active.

      3. Netty/CDI (or any arbitrary network based server). During the reception of a message over TCP, a request is active. Likewise, for the entire TCP connection a session context is active.

      4. Sparkjava/CDI. Assuming that sparkjava isn't running in a servlet container, during the execution of an arbitrary reactive method call, a request context is available for use.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            pmuir Pete Muir added a comment -

            Ok, we will cover scope at the phone call next week and come up with a statement.

            Show
            pmuir Pete Muir added a comment - Ok, we will cover scope at the phone call next week and come up with a statement.
            Hide
            shane.bryzak Shane Bryzak added a comment -

            There is no @ConversationScoped annotation in Seam 3 that I'm aware of. We need the management API to be able to support conversation management within view technologies other than JSF. Currently, we need to use a non-portable solution to achieve this, however it should have really been part of the CDI 1.0 specification and in my opinion it was an oversight that it was not included.

            Show
            shane.bryzak Shane Bryzak added a comment - There is no @ConversationScoped annotation in Seam 3 that I'm aware of. We need the management API to be able to support conversation management within view technologies other than JSF. Currently, we need to use a non-portable solution to achieve this, however it should have really been part of the CDI 1.0 specification and in my opinion it was an oversight that it was not included.
            Hide
            pmuir Pete Muir added a comment -

            Slipping Java SE related issues.

            Show
            pmuir Pete Muir added a comment - Slipping Java SE related issues.
            Hide
            atijms arjan tijms added a comment -

            John Ament
            First PR looks good!

            Would it be an idea to set a wrapped (or decorated) context controller?

            What I'm looking for is a way to start contexts possibly earlier than a specific container implementation normally starts them, and stop them possibly later. If the context is started earlier in say a request, then eventually the container will also start that same context later in the request. If that will throw an exception the request will not proceed, which is of course not intended.

            Likewise, when the container stops the context this will thus be too early.

            With a wrapped context controller, the startContexts and stopContexts calls can be ignored for those contexts the application (extension/library) wanted to start earlier and stop later. This does of course assume that the container itself will also use this context controller instead of the current proprietary code.

            Additionally, the PR does not contain the check anymore to see if the context is already active or already stopped. Is that still intended to be added? This would be particularly useful for code that needs to be portable between different containers, where one container may already have started the context at a given point, where another container has not (catching the exception would be an alternative here but is obviously not so nice).

            Another point, what about letting the caller of the startContexts method optionally pass in the objects (or a lambda to obtain them) on which that context primarily depends (if any). E.g. for the request scope, pass in an HttpServletRequest instance.

            Show
            atijms arjan tijms added a comment - John Ament First PR looks good! Would it be an idea to set a wrapped (or decorated) context controller? What I'm looking for is a way to start contexts possibly earlier than a specific container implementation normally starts them, and stop them possibly later. If the context is started earlier in say a request, then eventually the container will also start that same context later in the request. If that will throw an exception the request will not proceed, which is of course not intended. Likewise, when the container stops the context this will thus be too early. With a wrapped context controller, the startContexts and stopContexts calls can be ignored for those contexts the application (extension/library) wanted to start earlier and stop later. This does of course assume that the container itself will also use this context controller instead of the current proprietary code. Additionally, the PR does not contain the check anymore to see if the context is already active or already stopped. Is that still intended to be added? This would be particularly useful for code that needs to be portable between different containers, where one container may already have started the context at a given point, where another container has not (catching the exception would be an alternative here but is obviously not so nice). Another point, what about letting the caller of the startContexts method optionally pass in the objects (or a lambda to obtain them) on which that context primarily depends (if any). E.g. for the request scope, pass in an HttpServletRequest instance.
            Hide
            meetoblivion John Ament added a comment -

            HI Arjan,

            I always find it easier to discuss on ML's but will try to answer you here.

            I think what you're asking for is to intercept at the container level and change how they initialize. I'm curious, under what cases do you not have an active request?

            In addition, I think you're looking for the equivalent of Context.isActive. Part of me even wonders if swapping around the impl to be Context.activate() and Context.deactivate() may be better from a domain standpoint.

            Show
            meetoblivion John Ament added a comment - HI Arjan, I always find it easier to discuss on ML's but will try to answer you here. I think what you're asking for is to intercept at the container level and change how they initialize. I'm curious, under what cases do you not have an active request? In addition, I think you're looking for the equivalent of Context.isActive . Part of me even wonders if swapping around the impl to be Context.activate() and Context.deactivate() may be better from a domain standpoint.

              People

              • Assignee:
                meetoblivion John Ament
                Reporter:
                nickarls Nicklas Karlsson
              • Votes:
                2 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Development