hi mark, +1 since it could replace the "suspend/resume"-suggestion which is quite similar.
ManagedContext detach(); //instead of #suspend void attach(ManagedContext contextToResume); //instead of #resume however, we postponed it >for now< to concentrate on the simplification of the original proposal. regards, gerhard 2012/2/29 Mark Struberg <[email protected]> > 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? > >> >> > >> > > >> > > >
