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? >>> >> >>
