deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: CdiControl in Java EE?
Date Wed, 29 Feb 2012 17:25:20 GMT
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 <pmuir@redhat.com>
> To: deltaspike-dev@incubator.apache.org; Mark Struberg <struberg@yahoo.de>
> 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?
>> 
> 

Mime
View raw message