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. >

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&gt; 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&gt; 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. > >

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&gt; 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&gt; 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. > >