Mark, are you saying you would like to be able to attach a backing store (e.g. map) and activate / detach the backing store and deactivate for multiple threads using one api call for all threads. Any idea what the API would look like.
I think this is one to consider later. On 29 Feb 2012, at 18:51, Mark Struberg wrote: > 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? >>>>> >>>> >>> >>
