deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Muir <pm...@redhat.com>
Subject Re: CdiControl in Java EE?
Date Thu, 01 Mar 2012 14:55:13 GMT
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 <gerhard.petracek@gmail.com>
>> To: deltaspike-dev@incubator.apache.org
>> 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 <struberg@yahoo.de>
>> 
>>> 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