sounds really good! we could introduce a subset of this stuff in DS and provide a backward compatway for CDI-1.0 containers (beside using a different package)
LieGrue, strub ----- Original Message ----- > From: Pete Muir <[email protected]> > To: [email protected]; Mark Struberg <[email protected]> > Cc: > Sent: Wednesday, February 29, 2012 2:14 PM > Subject: Re: CdiControl in Java EE? > >T his 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? >> >
