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

[Antoine Sabot-Durand]

I think this approach very interesting for built-in context support on Java
SE. What bothers me is the use of this under Java EE. I don't say it
wouldn't be useful, but it adds a level of complexity that may puzzle users.
So my point is : shouldn't we limit this feature to SE only ?

Antoine

Le mar. 31 mai 2016 à 15:00, Martin Kouba <mkouba at redhat.com> a écrit :

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