Gerhard and I discussed this on IRC. I would propose altering the api to change activate() -> start(), deactivate() -> stop()
I would also propose removing invalidate() (as it needs to be called almost all the time, so it's silly to have it split out), and see if anyone needs the "suspend" behaviour IRL :-) On 29 Feb 2012, at 15:13, Pete Muir wrote: > I've added the proposed APIs to the doc. > > On 29 Feb 2012, at 14:18, Gerhard Petracek wrote: > >> i agree with pete. >> we can create a draft at [1]. >> >> regards, >> gerhard >> >> [1] >> https://cwiki.apache.org/confluence/display/DeltaSpike/CDI+1.1+Proposals#CDI1.1Proposals-ContextManagement >> >> >> >> 2012/2/29 Pete Muir <pm...@redhat.com> >> >>> This just reinforces my feeling that CDIControl and context lifecycle >>> management should be two separate APIs. Context control is relevant in Java >>> EE and SE. Container start/stop is only relevant in JavaSE. >>> >>> I would suggest that context lifecycle management should be dependent >>> scoped injectable bean(s), so that you can access it either in a CDI bean >>> or outside a CDI bean (and then control the other scopes). >>> >>> For inspiration for the context control, we could look at Weld, which >>> defines an API for context lifecycle management. As a quick example: >>> >>> class Foo { >>> >>> @Inject RequestContext requestContext; >>> >>> void ensureRequestContextActive() { >>> if (!requestContext.isActive()) { >>> requestContext.activate(); >>> } >>> } >>> >>> void endRequest() { >>> if (requestContext.isActive()) { >>> // e.g. Make sure any conversation that have timed out are >>> cleaned up, we split this out so that we don't force people to do this, in >>> case they are just restarting the request context for some reason >>> requestContext.invalidate(); >>> requestContext.deactivate(); >>> } >>> } >>> >>> } >>> >>> The API looks like: >>> >>> // We use an empty subclass to allow injecting by type >>> public interface RequestContext extends ManagedContext {} >>> >>> // Context is the standard CDI SPI >>> public interface ManagedContext extends Context { >>> >>> /** >>> * Activate the Context. >>> */ >>> public void activate(); >>> >>> /** >>> * Deactivate the Context, destroying any instances if the context is >>> invalid. >>> */ >>> public void deactivate(); >>> >>> /** >>> * Mark the context as due for destruction when deactivate is called. >>> */ >>> public void invalidate(); >>> >>> } >>> >>> Note that Weld mixes this lifecycle management API in with an abstraction >>> over the context backing store (allowing you to use e.g. the http session, >>> or a plain map you manage yourself, or whatever you want). I don't think we >>> necessarily need to introduce that to Deltaspike right now. >>> >>> A requested enhancement to this API for Weld, which I think we should >>> support is the ability to inject not only built in context objects, but any >>> that the user creates. I would suggest we do this based on extending >>> ManagedContext. >>> >>> When I wrote this, I modelled Request and Session identically (as above). >>> ApplicationContext (and SingletonContext) is not modelled as a managed >>> context, as I don't expect a user to be able to activate or deactivate it. >>> The Dependent context is also not modelled as a managed context, as it has >>> no lifecycle. I did create an interface for it, which simply extends >>> Context with no more methods, to allow consistent use of injection. >>> >>> Conversation context is obviously the more complex one ;-) It's modelled >>> as a managed context, and adds: >>> >>> * a method to access and mutate the parameter name used to carry the >>> conversation id (the parameter is got from the request context object). I >>> don't think we should have this in Deltaspike, as it's outside the spec by >>> a long way ;-) >>> * a method to access and mutate the concurrent access timeout *default* >>> for the app. This is useful I think, and I would assume all impls do >>> support this in some way >>> * a method to access and mutate the conversation inactivity timeout >>> *default* for the app. This is useful I think, and I would assume all impls >>> do support this in some way >>> * a method to get a list of all conversations the container knows about >>> (for this session), returns a List<ManagedConversation>, more below >>> * a method to get the conversation by ID, returns ManagedConversation >>> * a method to have the container generate a new conversation id using >>> whatever algorithm it wants >>> * a method to get the current active conversation >>> >>> ManagedConversation is a subclass of Conversation, and adds: >>> >>> * ability to lock and unlock the conversation (concurrent access) >>> * get the timestamp the conversation was last used >>> * "touch" which updates the last used timestamp to now >>> >>> I'm not sure Deltaspike needs ManagedConversation. >>> >>> You can read the full API at >>> https://github.com/weld/api/tree/master/weld/src/main/java/org/jboss/weld/context- >>> but ignore the sub packages, and the BoundContext interface, as they >>> relate to abstracting out the backing store. >>> >>> I think this approach would give a powerful, easy to use API for context >>> lifecycle management. It also has the benefit of ironing out the >>> differences between built in and user provided contexts, and provides a >>> model for extensions to create context lifecycle management APIs based on. >>> >>> WDYT? >>> >>> On 29 Feb 2012, at 07:53, Mark Struberg wrote: >>> >>>> Hi! >>>> >>>> Pete did ask me a few days ago if the CdiContainer is really only >>> targeted to JavaSE. >>>> Well, basically it _was_. But yesterday I reviewed the 3 Quartz >>> Extensions from Ronald, OpenKnowledge and Seam3 and when looking at the >>> first 2 I saw that >>>> >>>> 1.) OpenKnowledge introduces an own Context named @ThreadScoped and >>> start it manually in the newly started Quartz thread. >>>> >>>> 2.) our TISS Quartz Extension (done by Ronald) uses OWB specific code to >>> start a RequestScope for the newly started thread in which Quartz runs. >>>> >>>> I've not looked into the Seam3 extension in detail because it does a >>> hell lot more and I'm not sure if we really need all that. A few things >>> look really good but I didn't have enough time to plug them apart. >>>> >>>> What are the pros and cons of 1.) and 2.) so far? >>>> 1.) is CDI container independent but you must not use @RequestScoped >>> because this Context is not active in the new thread. You can use the new >>> @ThreadScoped but if you use the same @Transactional services for the >>> Quartz job and the rest of your app, then you must not use a @RequestScoped >>> EntityManager. >>>> >>>> >>>> 2.) Sharing the services between the Quartz job and the rest of the app >>> is perfectly fine but it's currently Container specific how the >>> @RequestScoped can get activated for a freshly created thread. >>>> >>>> >>>> And then Pete's words jumped into my head. >>>> >>>> >>>> So, what about using the CdiContainer#startContext(RequestScoped.class); >>> in that CDI Extension? >>>> That looks pretty much perfect to me! >>>> >>>> We could also provide multiple impls, e.g for: WeldSE, WeldEE, OwbSE, >>> OwbEE, ResinEE, >>>> >>>> Anyone could easily implement the control part himself if the standard >>> container integration doesn't work out of the box for a certain EE >>> container. >>>> If e.g. OwbEE will not work on WebSphere-8.0.2, then its easy to just >>> write an own! >>>> >>>> >>>> >>>> wdyt? >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> PS: Pete we might add some kind of Context-Control to the CDI-1.1 spec, >>> wdyt? >>>> >>> >>> >
