You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Pete Muir <pm...@redhat.com> on 2012/03/01 15:55:13 UTC
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 <ge...@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 <st...@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 <pm...@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?
>>>>>
>>>>
>>>
>>
Re: CdiControl in Java EE?
Posted by Mark Struberg <st...@yahoo.de>.
> Each Request will e.g. get an own Context instance!
correction: MIGHT get it's own instance. This is container specific.
LieGrue,
strub
----- Original Message -----
> From: Mark Struberg <st...@yahoo.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
> Cc:
> Sent: Saturday, March 10, 2012 2:21 PM
> Subject: Re: CdiControl in Java EE?
>
> 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 <st...@yahoo.de>
>> To: "deltaspike-dev@incubator.apache.org"
> <de...@incubator.apache.org>
>> 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 <pm...@redhat.com>
>>> To: deltaspike-dev@incubator.apache.org; Mark Struberg
>> <st...@yahoo.de>
>>> 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 <ge...@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 <st...@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 <pm...@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?
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>
Re: CdiControl in Java EE?
Posted by Mark Struberg <st...@yahoo.de>.
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 <st...@yahoo.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@incubator.apache.org>
> 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 <pm...@redhat.com>
>> To: deltaspike-dev@incubator.apache.org; Mark Struberg
> <st...@yahoo.de>
>> 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 <ge...@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 <st...@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 <pm...@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?
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
Re: CdiControl in Java EE?
Posted by Mark Struberg <st...@yahoo.de>.
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 <pm...@redhat.com>
> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@yahoo.de>
> 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 <ge...@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 <st...@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 <pm...@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?
>>>>>>
>>>>>
>>>>
>>>
>