One thing to point out - I explicitly didn't provide a way to manage
ConversationScope. There's two problems with it as I see it.
1. Its bound to a CID
2. The CID can only be passed in as an HTTP parameter
There's already an API that allows you to manage conversations, assuming
you get a reference to the Conversation bean. What's missing is loading an
active conversation. I think we can add something to have a long running
conversation if needed, otherwise leverage the Conversation bean to start
conversation scope.
Another point - mostly to reiterate Martin's sentiment. This is merely
starting the context to support already scoped beans. The javadocs on
session clearly state that there is no correlation between requests and a
session.
John
On Tue, May 31, 2016 at 9:00 AM Martin Kouba <mkouba(a)redhat.com> wrote:
I think John's proposal is defacto a standardized version of
"unbound
contexts" from Weld [1]. These are scoped to the thread in which they
are activated and destroyed upon deactivation. For @RequestScoped it
makes perfect sense (we use it internally in Weld if needed during
@PostConstruct callbacks). For @ConversationScoped and @SessionScoped it
would be more like a dummy context just to make beans working.
Actually, I find the Weld Context Management API quite nice and
powerful. But including all this stuff in the spec might be overkill.
Martin
[1]
http://docs.jboss.org/weld/reference/latest/en-US/html/contexts.html#_man...
Dne 31.5.2016 v 08:51 Mark Struberg napsal(a):
> Quick feedback:
>
> *) activate might be ambiguous. There is actually a ’start’ and a
‚activate on this very thread‘. Think about @SessionScoped or
@ConversationScoped. Not every new thread will start a new Context.
Multiple threads might re-use the very same one. Now you need a way to
explicitlely say which ’Session’ (or Map) you like to attach to
>
> *) @ActivateRequestScope et al. Interesting idea but I fear it wont work
out. Let’s stick with the @SessionScoped example: _which_ Session should
get created/attached for the very thread?
>
> But it’s a start! Thanks for getting the ball rolling.
>
> LieGrue,
> strub
>
>
>> Am 26.05.2016 um 12:42 schrieb John D. Ament <john.d.ament(a)gmail.com>:
>>
>> All,
>>
>> As mentioned during Tuesday's meeting, I'm looking for more feedback on
PR #291 - the context control APIs. I think the current version is pretty
snazy, and thanks especially to Martin for his input on it thus far. I'm
looking for more input though, especially from the OWB team (Mark
Struberg??) on whether its realistic or not.
>>
>>
https://github.com/cdi-spec/cdi/pull/291
>>
>>
>> John
>> _______________________________________________
>> 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.
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic