quick update: we might not only need start/stop context but also 'attach/detach'.
Reason: the only important point for a Context if it is active 'in respect to the current thread'. If you start a new thread manually, then there is no Context active for it. But for e.g. @SessionScoped, I don't like to create a new scope for all my 3 Quartz worker threads but only once and and just 'attach' them to the other threads. LieGrue, strub ----- Original Message ----- > From: Gerhard Petracek <[email protected]> > To: [email protected] > Cc: > Sent: Wednesday, February 29, 2012 6:46 PM > Subject: Re: CdiControl in Java EE? > > @mark: > that was exactly our intention. > > @others: > pete will simplify the api based on some objections and a concrete > suggestion. > -> afterwards we could prototype and discuss it in parallel. > > regards, > gerhard > > > > 2012/2/29 Mark Struberg <[email protected]> > >> 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? >> >> >> > >> >
