Getting this back to life again! The next steps are
1.) rename the project from cdise to cdicontrol because it is not only for SE anymore 1.) split between the CdiBoot API and the ContextControl The CdiBoot is for starting and shutting down the container in SE environments and will be provided via the CdiBootLoader. The ContextControl will not be implemented via static accessor methods anymore but as @Dependent beans via CDI producers for each container. @Dependent because this context is always active. 3.) we will for now just implement startContext and stopContext. We will defer activateContext and deactivateContext (in relation to the current thread) until later. wdyt? LieGrue, strub ----- Original Message ----- > From: Pete Muir <[email protected]> > To: [email protected]; Mark Struberg <[email protected]> > Cc: > Sent: Thursday, March 1, 2012 3:55 PM > Subject: Re: CdiControl in Java EE? > > 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? >>>>>> >>>>> >>>> >>> >
