Recap of Context Management (CDI-30) hangout meeting

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Recap of Context Management (CDI-30) hangout meeting

Antoine Sabot-Durand
Administrator
Hi all,

Just to sum up what was said during our Tuesday Hangout meeting. For those who were present feel free to correct or amend this.

Controlling Request Context is something rather easy (because it's linked to one thread) while Session Context is far less obvious (used across multiple threads) so providing a generic solution to deal with their control seems quite complicated.
That's why we decided to start addressing the Request Context control first and if we fell happy with that, continue the work on the Session Context.

Public API to control the request context could be design in 2 different ways:
1) provide an interceptor to activate request context during the intercepted method invocation
2) provide a programmatic API accessible thru a bean (like the Conversation bean)

First solution is probably the easiest way for end user (to avoid not ended context), but if we go for controlling Session Scope we won't be able to provide a simple interceptor for it and will design something like solution 2 for it.

So the question is should we go for 1 or 2 or both (with a risk of confusion) ?

Thanks for your feedback

Antoine
 

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Recap of Context Management (CDI-30) hangout meeting

Martin Kouba

Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a):

> Hi all,
>
> Just to sum up what was said during our Tuesday Hangout meeting. For
> those who were present feel free to correct or amend this.
>
> Controlling Request Context is something rather easy (because it's
> linked to one thread) while Session Context is far less obvious (used
> across multiple threads) so providing a generic solution to deal with
> their control seems quite complicated.
> That's why we decided to start addressing the Request Context control
> first and if we fell happy with that, continue the work on the Session
> Context.
>
> Public API to control the request context could be design in 2 different
> ways:
> 1) provide an interceptor to activate request context during the
> intercepted method invocation

This approach is also not always usable in some integration use cases
where the request cannot be simply "wrapped in a single method call".

For instance, in Quartz scheduler you can register a job listener with
methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() -
here the approach 2) would make sense. On the other hand, you could
implement a JobFactory so that Job instances are beans (or at least
instances obtained and injected from an InjectionTarget) and simply
associate interceptor binding for its execute() method.

> 2) provide a programmatic API accessible thru a bean (like the
> Conversation bean)
>
> First solution is probably the easiest way for end user (to avoid not
> ended context), but if we go for controlling Session Scope we won't be
> able to provide a simple interceptor for it and will design something
> like solution 2 for it.
>
> So the question is should we go for 1 or 2 or both (with a risk of
> confusion) ?

I think that both ways are legal and make sense.

>
> Thanks for your feedback
>
> Antoine
>
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Recap of Context Management (CDI-30) hangout meeting

Antoine Sabot-Durand
Administrator
That's also my choice:
We should provide 2) for advance usage and consistency sake if we go for Session context control later AND we should provide 1) for an easy usage of this feature.

A well written JavaDoc should prevent confusion between both approach.

Antoine

On Thu, Sep 29, 2016 at 11:46 AM Martin Kouba <[hidden email]> wrote:

Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a):
> Hi all,
>
> Just to sum up what was said during our Tuesday Hangout meeting. For
> those who were present feel free to correct or amend this.
>
> Controlling Request Context is something rather easy (because it's
> linked to one thread) while Session Context is far less obvious (used
> across multiple threads) so providing a generic solution to deal with
> their control seems quite complicated.
> That's why we decided to start addressing the Request Context control
> first and if we fell happy with that, continue the work on the Session
> Context.
>
> Public API to control the request context could be design in 2 different
> ways:
> 1) provide an interceptor to activate request context during the
> intercepted method invocation

This approach is also not always usable in some integration use cases
where the request cannot be simply "wrapped in a single method call".

For instance, in Quartz scheduler you can register a job listener with
methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() -
here the approach 2) would make sense. On the other hand, you could
implement a JobFactory so that Job instances are beans (or at least
instances obtained and injected from an InjectionTarget) and simply
associate interceptor binding for its execute() method.

> 2) provide a programmatic API accessible thru a bean (like the
> Conversation bean)
>
> First solution is probably the easiest way for end user (to avoid not
> ended context), but if we go for controlling Session Scope we won't be
> able to provide a simple interceptor for it and will design something
> like solution 2 for it.
>
> So the question is should we go for 1 or 2 or both (with a risk of
> confusion) ?

I think that both ways are legal and make sense.

>
> Thanks for your feedback
>
> Antoine
>
>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Recap of Context Management (CDI-30) hangout meeting

Mark Struberg
Martins argument with Quartz is a good one.


Having 2 different ways to do the same thing might be making things too complicated. You also have to think about what happens if a user or libraries would mix the 2 approaches?

So my vote is for the programmatic approach.


Oh and while we are at it:
If we introduce some 'RequestContextControl' bean, should it also contain a isActive() method? Otherwise we might get into troubles with nesting such code.
Of course it is possible by code like


try {
  beanManager.getContext(RequestScoped.class);
  // request context is active
}

catch (ContextNotActiveException cnae) {
  // request context is not active
  // start it etc.

}


But that seems a bit heavyweight, isn't?

LieGrue,
strub



On Thursday, 29 September 2016, 11:58, Antoine Sabot-Durand <[hidden email]> wrote:


>
>
>That's also my choice:
>We should provide 2) for advance usage and consistency sake if we go for Session context control later AND we should provide 1) for an easy usage of this feature.
>
>
>A well written JavaDoc should prevent confusion between both approach.
>
>
>Antoine
>
>On Thu, Sep 29, 2016 at 11:46 AM Martin Kouba <[hidden email]> wrote:
>
>
>>Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a):
>>> Hi all,
>>>
>>> Just to sum up what was said during our Tuesday Hangout meeting. For
>>> those who were present feel free to correct or amend this.
>>>
>>> Controlling Request Context is something rather easy (because it's
>>> linked to one thread) while Session Context is far less obvious (used
>>> across multiple threads) so providing a generic solution to deal with
>>> their control seems quite complicated.
>>> That's why we decided to start addressing the Request Context control
>>> first and if we fell happy with that, continue the work on the Session
>>> Context.
>>>
>>> Public API to control the request context could be design in 2 different
>>> ways:
>>> 1) provide an interceptor to activate request context during the
>>> intercepted method invocation
>>
>>This approach is also not always usable in some integration use cases
>>where the request cannot be simply "wrapped in a single method call".
>>
>>For instance, in Quartz scheduler you can register a job listener with
>>methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() -
>>here the approach 2) would make sense. On the other hand, you could
>>implement a JobFactory so that Job instances are beans (or at least
>>instances obtained and injected from an InjectionTarget) and simply
>>associate interceptor binding for its execute() method.
>>
>>> 2) provide a programmatic API accessible thru a bean (like the
>>> Conversation bean)
>>>
>>> First solution is probably the easiest way for end user (to avoid not
>>> ended context), but if we go for controlling Session Scope we won't be
>>> able to provide a simple interceptor for it and will design something
>>> like solution 2 for it.
>>>
>>> So the question is should we go for 1 or 2 or both (with a risk of
>>> confusion) ?
>>
>>I think that both ways are legal and make sense.
>>
>>>
>>> Thanks for your feedback
>>>
>>> Antoine
>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>
>>
>
>_______________________________________________
>cdi-dev mailing list
>[hidden email]
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>
>
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Recap of Context Management (CDI-30) hangout meeting

Martin Kouba
Dne 29.9.2016 v 12:59 Mark Struberg napsal(a):
> Martins argument with Quartz is a good one.
>
>
> Having 2 different ways to do the same thing might be making things too complicated. You also have to think about what happens if a user or libraries would mix the 2 approaches?

That's a good point. But I think it should be ok to state that
activate() is no-op if the request context is already active (and the
same for interceptor). I.e. both the interceptor and the
RequestContextControl bean should perform the check described below.

>
> So my vote is for the programmatic approach.
>
>
> Oh and while we are at it:
> If we introduce some 'RequestContextControl' bean, should it also contain a isActive() method? Otherwise we might get into troubles with nesting such code.
> Of course it is possible by code like
>
>
> try {
>   beanManager.getContext(RequestScoped.class);
>   // request context is active
> }
>
> catch (ContextNotActiveException cnae) {
>   // request context is not active
>   // start it etc.
>
> }
>
>
> But that seems a bit heavyweight, isn't?
>
> LieGrue,
> strub
>
>
>
> On Thursday, 29 September 2016, 11:58, Antoine Sabot-Durand <[hidden email]> wrote:
>
>
>>
>>
>> That's also my choice:
>> We should provide 2) for advance usage and consistency sake if we go for Session context control later AND we should provide 1) for an easy usage of this feature.
>>
>>
>> A well written JavaDoc should prevent confusion between both approach.
>>
>>
>> Antoine
>>
>> On Thu, Sep 29, 2016 at 11:46 AM Martin Kouba <[hidden email]> wrote:
>>
>>
>>> Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a):
>>>> Hi all,
>>>>
>>>> Just to sum up what was said during our Tuesday Hangout meeting. For
>>>> those who were present feel free to correct or amend this.
>>>>
>>>> Controlling Request Context is something rather easy (because it's
>>>> linked to one thread) while Session Context is far less obvious (used
>>>> across multiple threads) so providing a generic solution to deal with
>>>> their control seems quite complicated.
>>>> That's why we decided to start addressing the Request Context control
>>>> first and if we fell happy with that, continue the work on the Session
>>>> Context.
>>>>
>>>> Public API to control the request context could be design in 2 different
>>>> ways:
>>>> 1) provide an interceptor to activate request context during the
>>>> intercepted method invocation
>>>
>>> This approach is also not always usable in some integration use cases
>>> where the request cannot be simply "wrapped in a single method call".
>>>
>>> For instance, in Quartz scheduler you can register a job listener with
>>> methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() -
>>> here the approach 2) would make sense. On the other hand, you could
>>> implement a JobFactory so that Job instances are beans (or at least
>>> instances obtained and injected from an InjectionTarget) and simply
>>> associate interceptor binding for its execute() method.
>>>
>>>> 2) provide a programmatic API accessible thru a bean (like the
>>>> Conversation bean)
>>>>
>>>> First solution is probably the easiest way for end user (to avoid not
>>>> ended context), but if we go for controlling Session Scope we won't be
>>>> able to provide a simple interceptor for it and will design something
>>>> like solution 2 for it.
>>>>
>>>> So the question is should we go for 1 or 2 or both (with a risk of
>>>> confusion) ?
>>>
>>> I think that both ways are legal and make sense.
>>>
>>>>
>>>> Thanks for your feedback
>>>>
>>>> Antoine
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>>
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Recap of Context Management (CDI-30) hangout meeting

Emily Jiang
My choice is also:
provide 2 solutions.

I would expect most user cases can be solved by the solution 1. Only advanced users would use the solution 2.

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Architect, Development Lead

 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        Martin Kouba <[hidden email]>
To:        Mark Struberg <[hidden email]>, Antoine Sabot-Durand <[hidden email]>, cdi-dev <[hidden email]>
Date:        29/09/2016 12:16
Subject:        Re: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting
Sent by:        [hidden email]




Dne 29.9.2016 v 12:59 Mark Struberg napsal(a):
> Martins argument with Quartz is a good one.
>
>
> Having 2 different ways to do the same thing might be making things too complicated. You also have to think about what happens if a user or libraries would mix the 2 approaches?

That's a good point. But I think it should be ok to state that
activate() is no-op if the request context is already active (and the
same for interceptor). I.e. both the interceptor and the
RequestContextControl bean should perform the check described below.

>
> So my vote is for the programmatic approach.
>
>
> Oh and while we are at it:
> If we introduce some 'RequestContextControl' bean, should it also contain a isActive() method? Otherwise we might get into troubles with nesting such code.
> Of course it is possible by code like
>
>
> try {
>   beanManager.getContext(RequestScoped.class);
>   // request context is active
> }
>
> catch (ContextNotActiveException cnae) {
>   // request context is not active
>   // start it etc.
>
> }
>
>
> But that seems a bit heavyweight, isn't?
>
> LieGrue,
> strub
>
>
>
> On Thursday, 29 September 2016, 11:58, Antoine Sabot-Durand <[hidden email]> wrote:
>
>
>>
>>
>> That's also my choice:
>> We should provide 2) for advance usage and consistency sake if we go for Session context control later AND we should provide 1) for an easy usage of this feature.
>>
>>
>> A well written JavaDoc should prevent confusion between both approach.
>>
>>
>> Antoine
>>
>> On Thu, Sep 29, 2016 at 11:46 AM Martin Kouba <[hidden email]> wrote:
>>
>>
>>> Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a):
>>>> Hi all,
>>>>
>>>> Just to sum up what was said during our Tuesday Hangout meeting. For
>>>> those who were present feel free to correct or amend this.
>>>>
>>>> Controlling Request Context is something rather easy (because it's
>>>> linked to one thread) while Session Context is far less obvious (used
>>>> across multiple threads) so providing a generic solution to deal with
>>>> their control seems quite complicated.
>>>> That's why we decided to start addressing the Request Context control
>>>> first and if we fell happy with that, continue the work on the Session
>>>> Context.
>>>>
>>>> Public API to control the request context could be design in 2 different
>>>> ways:
>>>> 1) provide an interceptor to activate request context during the
>>>> intercepted method invocation
>>>
>>> This approach is also not always usable in some integration use cases
>>> where the request cannot be simply "wrapped in a single method call".
>>>
>>> For instance, in Quartz scheduler you can register a job listener with
>>> methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() -
>>> here the approach 2) would make sense. On the other hand, you could
>>> implement a JobFactory so that Job instances are beans (or at least
>>> instances obtained and injected from an InjectionTarget) and simply
>>> associate interceptor binding for its execute() method.
>>>
>>>> 2) provide a programmatic API accessible thru a bean (like the
>>>> Conversation bean)
>>>>
>>>> First solution is probably the easiest way for end user (to avoid not
>>>> ended context), but if we go for controlling Session Scope we won't be
>>>> able to provide a simple interceptor for it and will design something
>>>> like solution 2 for it.
>>>>
>>>> So the question is should we go for 1 or 2 or both (with a risk of
>>>> confusion) ?
>>>
>>> I think that both ways are legal and make sense.
>>>
>>>>
>>>> Thanks for your feedback
>>>>
>>>> Antoine
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> [hidden email]
>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>>
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Reply | Threaded
Open this post in threaded view
|

Re: Recap of Context Management (CDI-30) hangout meeting

John Ament

I was thinking about that as well.  I agree with having both available, and both being able to do an activateIfNotActive() method (whether thats the activate() method or something else)




From: [hidden email] <[hidden email]> on behalf of Emily Jiang <[hidden email]>
Sent: Thursday, September 29, 2016 8:48 AM
To: Martin Kouba
Cc: cdi-dev
Subject: Re: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting
 
My choice is also:
provide 2 solutions.

I would expect most user cases can be solved by the solution 1. Only advanced users would use the solution 2.

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI Architect, Development Lead

 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: [hidden email]
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        Martin Kouba <[hidden email]>
To:        Mark Struberg <[hidden email]>, Antoine Sabot-Durand <[hidden email]>, cdi-dev <[hidden email]>
Date:        29/09/2016 12:16
Subject:        Re: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting
Sent by:        [hidden email]




Dne 29.9.2016 v 12:59 Mark Struberg napsal(a):
> Martins argument with Quartz is a good one.
>
>
> Having 2 different ways to do the same thing might be making things too complicated. You also have to think about what happens if a user or libraries would mix the 2 approaches?

That's a good point. But I think it should be ok to state that
activate() is no-op if the request context is already active (and the
same for interceptor). I.e. both the interceptor and the
RequestContextControl bean should perform the check described below.

>
> So my vote is for the programmatic approach.
>
>
> Oh and while we are at it:
> If we introduce some 'RequestContextControl' bean, should it also contain a isActive() method? Otherwise we might get into troubles with nesting such code.
> Of course it is possible by code like
>
>
> try {
>   beanManager.getContext(RequestScoped.class);
>   // request context is active
> }
>
> catch (ContextNotActiveException cnae) {
>   // request context is not active
>   // start it etc.
>
> }
>
>
> But that seems a bit heavyweight, isn't?
>
> LieGrue,
> strub
>
>
>
> On Thursday, 29 September 2016, 11:58, Antoine Sabot-Durand <[hidden email]> wrote:
>
>
>>
>>
>> That's also my choice:
>> We should provide 2) for advance usage and consistency sake if we go for Session context control later AND we should provide 1) for an easy usage of this feature.
>>
>>
>> A well written JavaDoc should prevent confusion between both approach.
>>
>>
>> Antoine
>>
>> On Thu, Sep 29, 2016 at 11:46 AM Martin Kouba <[hidden email]> wrote:
>>
>>
>>> Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a):
>>>> Hi all,
>>>>
>>>> Just to sum up what was said during our Tuesday Hangout meeting. For
>>>> those who were present feel free to correct or amend this.
>>>>
>>>> Controlling Request Context is something rather easy (because it's
>>>> linked to one thread) while Session Context is far less obvious (used
>>>> across multiple threads) so providing a generic solution to deal with
>>>> their control seems quite complicated.
>>>> That's why we decided to start addressing the Request Context control
>>>> first and if we fell happy with that, continue the work on the Session
>>>> Context.
>>>>
>>>> Public API to control the request context could be design in 2 different
>>>> ways:
>>>> 1) provide an interceptor to activate request context during the
>>>> intercepted method invocation
>>>
>>> This approach is also not always usable in some integration use cases
>>> where the request cannot be simply "wrapped in a single method call".
>>>
>>> For instance, in Quartz scheduler you can register a job listener with
>>> methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted() -
>>> here the approach 2) would make sense. On the other hand, you could
>>> implement a JobFactory so that Job instances are beans (or at least
>>> instances obtained and injected from an InjectionTarget) and simply
>>> associate interceptor binding for its execute() method.
>>>
>>>> 2) provide a programmatic API accessible thru a bean (like the
>>>> Conversation bean)
>>>>
>>>> First solution is probably the easiest way for end user (to avoid not
>>>> ended context), but if we go for controlling Session Scope we won't be
>>>> able to provide a simple interceptor for it and will design something
>>>> like solution 2 for it.
>>>>
>>>> So the question is should we go for 1 or 2 or both (with a risk of
>>>> confusion) ?
>>>
>>> I think that both ways are legal and make sense.
>>>
>>>>
>>>> Thanks for your feedback
>>>>
>>>> Antoine
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> [hidden email]
>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>>>
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>>
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

lists.jboss.org
List to discuss the development of CDI (the specification) To see the collection of prior postings to the list, visit the cdi-dev Archives.

www.apache.org
Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION. 1. Definitions.



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.