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 <[email protected]> > 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? > > > >
