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: cdi-dev-bounces@lists.jboss.org <cdi-dev-bounces@lists.jboss.org> on behalf of Emily Jiang <EMIJIANG@uk.ibm.com>
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: emijiang@uk.ibm.com
Lotus Notes: Emily Jiang/UK/IBM@IBMGB




From:        Martin Kouba <mkouba@redhat.com>
To:        Mark Struberg <struberg@yahoo.de>, Antoine Sabot-Durand <antoine@sabot-durand.net>, cdi-dev <cdi-dev@lists.jboss.org>
Date:        29/09/2016 12:16
Subject:        Re: [cdi-dev] Recap of Context Management (CDI-30) hangout meeting
Sent by:        cdi-dev-bounces@lists.jboss.org



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 <antoine@sabot-durand.net> 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 <mkouba@redhat.com> 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
>>>> cdi-dev@lists.jboss.org
>>>> 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
>> cdi-dev@lists.jboss.org
>> 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
cdi-dev@lists.jboss.org
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.