<font size=2 face="sans-serif">My choice is also:</font>
<br><font size=2 face="sans-serif">provide 2 solutions.</font>
<br>
<br><font size=2 face="sans-serif">I would expect most user cases can be
solved by the solution 1. Only advanced users would use the solution 2.</font>
<br>
<br><font size=2 face="sans-serif">Many thanks,<br>
Emily<br>
===========================<br>
Emily Jiang<br>
WebSphere Application Server, CDI Architect, Development Lead</font>
<br><font size=2 face="sans-serif"> <br>
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN<br>
Phone: +44 (0)1962 816278 Internal: 246278<br>
<br>
Email: emijiang@uk.ibm.com <br>
Lotus Notes: Emily Jiang/UK/IBM@IBMGB<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Martin Kouba <mkouba@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Mark Struberg <struberg@yahoo.de>,
Antoine Sabot-Durand <antoine@sabot-durand.net>, cdi-dev <cdi-dev@lists.jboss.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">29/09/2016 12:16</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [cdi-dev]
Recap of Context Management (CDI-30) hangout meeting</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">cdi-dev-bounces@lists.jboss.org</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Dne 29.9.2016 v 12:59 Mark Struberg napsal(a):<br>
> Martins argument with Quartz is a good one.<br>
><br>
><br>
> 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?<br>
<br>
That's a good point. But I think it should be ok to state that <br>
activate() is no-op if the request context is already active (and the <br>
same for interceptor). I.e. both the interceptor and the <br>
RequestContextControl bean should perform the check described below.<br>
<br>
><br>
> So my vote is for the programmatic approach.<br>
><br>
><br>
> Oh and while we are at it:<br>
> If we introduce some 'RequestContextControl' bean, should it also
contain a isActive() method? Otherwise we might get into troubles with
nesting such code.<br>
> Of course it is possible by code like<br>
><br>
><br>
> try {<br>
> beanManager.getContext(RequestScoped.class);<br>
> // request context is active<br>
> }<br>
><br>
> catch (ContextNotActiveException cnae) {<br>
> // request context is not active<br>
> // start it etc.<br>
><br>
> }<br>
><br>
><br>
> But that seems a bit heavyweight, isn't?<br>
><br>
> LieGrue,<br>
> strub<br>
><br>
><br>
><br>
> On Thursday, 29 September 2016, 11:58, Antoine Sabot-Durand <antoine@sabot-durand.net>
wrote:<br>
><br>
><br>
>><br>
>><br>
>> That's also my choice:<br>
>> 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.<br>
>><br>
>><br>
>> A well written JavaDoc should prevent confusion between both approach.<br>
>><br>
>><br>
>> Antoine<br>
>><br>
>> On Thu, Sep 29, 2016 at 11:46 AM Martin Kouba <mkouba@redhat.com>
wrote:<br>
>><br>
>><br>
>>> Dne 29.9.2016 v 11:16 Antoine Sabot-Durand napsal(a):<br>
>>>> Hi all,<br>
>>>><br>
>>>> Just to sum up what was said during our Tuesday Hangout
meeting. For<br>
>>>> those who were present feel free to correct or amend this.<br>
>>>><br>
>>>> Controlling Request Context is something rather easy (because
it's<br>
>>>> linked to one thread) while Session Context is far less
obvious (used<br>
>>>> across multiple threads) so providing a generic solution
to deal with<br>
>>>> their control seems quite complicated.<br>
>>>> That's why we decided to start addressing the Request
Context control<br>
>>>> first and if we fell happy with that, continue the work
on the Session<br>
>>>> Context.<br>
>>>><br>
>>>> Public API to control the request context could be design
in 2 different<br>
>>>> ways:<br>
>>>> 1) provide an interceptor to activate request context
during the<br>
>>>> intercepted method invocation<br>
>>><br>
>>> This approach is also not always usable in some integration
use cases<br>
>>> where the request cannot be simply "wrapped in a single
method call".<br>
>>><br>
>>> For instance, in Quartz scheduler you can register a job listener
with<br>
>>> methods jobToBeExecuted(), jobExecutionVetoed() and jobWasExecuted()
-<br>
>>> here the approach 2) would make sense. On the other hand,
you could<br>
>>> implement a JobFactory so that Job instances are beans (or
at least<br>
>>> instances obtained and injected from an InjectionTarget) and
simply<br>
>>> associate interceptor binding for its execute() method.<br>
>>><br>
>>>> 2) provide a programmatic API accessible thru a bean (like
the<br>
>>>> Conversation bean)<br>
>>>><br>
>>>> First solution is probably the easiest way for end user
(to avoid not<br>
>>>> ended context), but if we go for controlling Session Scope
we won't be<br>
>>>> able to provide a simple interceptor for it and will design
something<br>
>>>> like solution 2 for it.<br>
>>>><br>
>>>> So the question is should we go for 1 or 2 or both (with
a risk of<br>
>>>> confusion) ?<br>
>>><br>
>>> I think that both ways are legal and make sense.<br>
>>><br>
>>>><br>
>>>> Thanks for your feedback<br>
>>>><br>
>>>> Antoine<br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> cdi-dev mailing list<br>
>>>> cdi-dev@lists.jboss.org<br>
>>>> </font></tt><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev"><tt><font size=2>https://lists.jboss.org/mailman/listinfo/cdi-dev</font></tt></a><tt><font size=2><br>
>>>><br>
>>>> Note that for all code provided on this list, the provider
licenses the code under the Apache License, Version 2 (</font></tt><a href="http://www.apache.org/licenses/LICENSE-2.0.html"><tt><font size=2>http://www.apache.org/licenses/LICENSE-2.0.html</font></tt></a><tt><font size=2>).
For all other ideas provided on this list, the provider waives all patent
and other intellectual property rights inherent in such information.<br>
>>>><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> cdi-dev@lists.jboss.org<br>
>> </font></tt><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev"><tt><font size=2>https://lists.jboss.org/mailman/listinfo/cdi-dev</font></tt></a><tt><font size=2><br>
>><br>
>> Note that for all code provided on this list, the provider licenses
the code under the Apache License, Version 2 (</font></tt><a href="http://www.apache.org/licenses/LICENSE-2.0.html"><tt><font size=2>http://www.apache.org/licenses/LICENSE-2.0.html</font></tt></a><tt><font size=2>).
For all other ideas provided on this list, the provider waives all patent
and other intellectual property rights inherent in such information.<br>
>><br>
>><br>
_______________________________________________<br>
cdi-dev mailing list<br>
cdi-dev@lists.jboss.org<br>
</font></tt><a href="https://lists.jboss.org/mailman/listinfo/cdi-dev"><tt><font size=2>https://lists.jboss.org/mailman/listinfo/cdi-dev</font></tt></a><tt><font size=2><br>
<br>
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (</font></tt><a href="http://www.apache.org/licenses/LICENSE-2.0.html"><tt><font size=2>http://www.apache.org/licenses/LICENSE-2.0.html</font></tt></a><tt><font size=2>).
For all other ideas provided on this list, the provider waives all patent
and other intellectual property rights inherent in such information.<br>
<br>
</font></tt>
<br><font size=2 face="sans-serif"><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU<br>
</font>