Hi! I've now reviewed
https://cwiki.apache.org/DeltaSpike/cdi-11-proposals.html and I think the ManagedContext extends Context has a very basic defunct. Let's look at the methods the Context interface defines: public Class<? extends Annotation> getScope(); public <T> T get(Contextual<T> component); public <T> T get(Contextual<T> component, CreationalContext<T> creationalContext); boolean isActive(); All these methods are targeted at a very Context instance. Each Request will e.g. get an own Context instance! But the ManagedContext interface defined in the wiki page is NOT yet bound to a Request. It is more a ContextControl actually, because calling #start() will actually even create a NEW Context! Those are completely orthogonal concerns really. Thus the is-a relation is just wrong imo. You just don't know upfront whether you will get an existing Context or create a new Context. LieGrue, strub ----- Original Message ----- > From: Mark Struberg <[email protected]> > To: "[email protected]" > <[email protected]> > Cc: > Sent: Saturday, March 10, 2012 11:10 AM > Subject: Re: CdiControl in Java EE? > >G etting 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? >>>>>>> >>>>>> >>>>> >>>> >> >
