[cdi-dev] Looking for Feedback on PR #291

John D. Ament john.d.ament at gmail.com
Tue May 31 10:18:52 EDT 2016


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 at 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#_managing_the_built_in_contexts
>
> 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 at 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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160531/ce882863/attachment-0001.html 


More information about the cdi-dev mailing list