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
<antoine(a)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(a)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(a)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(a)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.