[cdi-dev] On @RequestScoped hack

Wed Jun 24 07:12:43 EDT 2015

@Mark: not sure I follow, if we have:

/** * Start the specified scope. This only works for scopes which are
handled * by the CDI container itself. Custom scoped of 3rd party * Context
implementations shall be started directly (they are portable anyway). * *
@param scopeClass e.g. RequestScoped.class */ void startContext(Class<?
extends Annotation> scopeClass); /** * Stop the specified scope. This only
works for scopes which are handled * by the CDI container itself. Custom
scoped of 3rd party * Context implementations shall be stopped directly
(they are portable anyway). * * @param scopeClass e.g. RequestScoped.class
*/ void stopContext(Class<? extends Annotation> scopeClass);

Then we aredone and it works even in EE since context can be alterable now
- this is clearly something to discuss inbetween EDR and final but
introducing this API solves the SE case and doesnt break the EE one.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-06-24 13:05 GMT+02:00 Mark Struberg <struberg at yahoo.de>:

> No because the DS solution is not enough for the CDI spec. We need a
> mixture of features. At least if it should also be usable in EE.
> What we miss in DS is that you can give a well defined ’storage’ from
> outside. You can just start the SessionScope but it is always only for the
> current thread. Any other Thread will get a new context storage underneath.
> This is great if you just need some code which uses @SessionScoped to work
> somehow. But I think this is not enough if we want something inside the
> spec.
>
> LieGrue,
> strub
>
>
>
> > Am 24.06.2015 um 12:07 schrieb Romain Manni-Bucau <rmannibucau at gmail.com
> >:
> >
> > the issue isnot hqving something temporary but something temporary and
> really different from the final solution we seem to all desire.
> >
> > Stupid question surely but qsking it qnyway: cant we add a
> ContextControl taken from deltaspike in the EDR and the refine it? sounds
> like a closer solution than activating a scope then removing this.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >
> > 2015-06-24 12:04 GMT+02:00 Antoine Sabot-Durand <
> antoine at sabot-durand.net>:
> > Ok, let me phrase it again: "the EDR is not a partial spec, feature in
> it can be amend, changed or totally removed". It's main purpose is to have
> our end users feedback.
> > This idea of having a temporary specified part was introduced nearly 2
> months ago and was discussed many time... Would have been nice to have this
> discussion before doing the work.
> >
> >
> > Le mer. 24 juin 2015 à 11:41, Romain Manni-Bucau <rmannibucau at gmail.com>
> a écrit :
> > @Antoine: didnt complain about the in progress status. Just prefer as
> Jozef to not put something we ll revert which will lock us as @New did but
> in a worse manner. Said otherwise better to not do than doing it wrong
> knowing it is wrong.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> >
> > 2015-06-24 11:39 GMT+02:00 Antoine Sabot-Durand <
> antoine at sabot-durand.net>:
> > Romain,
> >
> > CDI-26 was open 4,5 years ago. Obviously working on the whole stuff in
> one shot didn't made it. To get out of the dead end I didn't see other
> solution than to cut the features in smaller pieces. That's why it's not
> finished and I intend to explain it in my blog post. As I'll explain that
> the EDR is for testing not early adoption.
> >
> >
> >
> > Le mer. 24 juin 2015 à 11:31, Antoine Sabot-Durand <
> antoine at sabot-durand.net> a écrit :
> > Jozef,
> >
> > I think I really got your disagreement on that point. You repeated it
> many times.
> >
> > My point and the question I keep asking to you is "what is your
> suggestion?".
> > Personally I see 5 solutions here:
> >
> > 1) Don't do anything since there's no alternative solution
> > 2) Change the wording regarding request scope activation in something
> like "is active from the initialization of the container until its shutdown"
> > 3) Give the same behavior than application scope request scope is shared
> > 4) Revert and say that Request Scope is not active in SE. But it's also
> a hack since we'll change it with CDI-530
> > 5) Don't specify anything
> >
> > I guess that you're choice is 4 or 5, but I may be wrong again, so why
> not tell us what you'd like to see and save us some time ?
> >
> > thanks
> >
> > Antoine
> >
> >
> >
> > Le mer. 24 juin 2015 à 11:13, Mark Struberg <struberg at yahoo.de> a écrit
> :
> > Jozef, read the rest of the meeting minutes as well. Throne and I
> enlisted dozen of REAL use cases where it is needed.
> >
> > > Does the @RequestScoped hack really address customers' problem?
> > Yes it does. In the final spec a programmer could programmatically
> enable the request context and ends it again IF he needs it. But today he
> cannot. And many users code really needs it. So the only thing we can do
> TODAY is to enable it by default.
> >
> > > * A CDI implementation may add such hack by itself - no need to have it
> > > the spec temporarily
> > Well that is an option but the users then cannot rely on it.
> >
> >
> > And no, it is perfectly implementable as it is worded right now.
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 24.06.2015 um 10:50 schrieb Jozef Hartinger <jharting at redhat.com>:
> > >
> > > Hi all,
> > >
> > > unfortunately I did not make it to the meeting yesterday. After reading
> > > the transcript I found out that the @RequestScoped hack is still being
> > > added to the EDR. What do I mean by "@RequestScoped hack"?
> > > By that I am referring to the following part of the spec:
> > >
> > > "
> > > In Java SE:
> > > The request scope is active during any method invocation.
> > > The request context is destroyed when the container is shut down.
> > > "
> > >
> > > This is vague, almost undefined and not correctly implementable. Most
> > > importantly, everyone seems to agree that it would be a bad idea for
> > > this to end up in the final spec. Instead, it is supposed to be
> replaced
> > > entirely by ContextControl API (
> https://issues.jboss.org/browse/CDI-530)
> > > post EDR1.
> > >
> > > Yet, we are adding this hack to EDR1 for the meantime. Why? The only
> > > argument to back this was "supporting existing libraries and
> applications".
> > >
> > > That seems reasonable, doesn't it? Well, no. Antoine took a detailed
> > > look into probably the most prominent CDI library - DeltaSpike. Yes,
> you
> > > can find @RequestScoped beans in DeltaSpike. You can find Servlet
> > > artifact producers, JSF view root and navigation handlers, etc. And
> > > that's it. Nothing one could really use outside of the EE stack.
> > >
> > > That's not a coincidence. When a user marks a bean as @RequestScoped we
> > > can assume they do it for a reason. The reason most likely would be to
> > > scope the state per "task" (often HTTP request processing) and isolate
> > > the state from the state of other tasks. That's very different from the
> > > @Singleton-like behavior that the @RequestScoped hack adds. Therefore,
> > > even if a library exists that relies on @RequestScoped it is not going
> > > to work properly anyway. The @RequestScoped hack just suppresses a fast
> > > failure and trades it for weird state inconsistencies later.
> > >
> > > Another part of the argument is "existing applications". More
> specifically:
> > >
> > > "struberg: well, I have a few customers with 10k++ classes. And some
> > > core components use it heavily"
> > >
> > > Does the @RequestScoped hack really address customers' problem?
> Remember
> > > that the @RequestScoped hack is planned to be temporary and replaced
> > > with proper context control post EDR1.
> > > Are those customers planning to migrate to EDR1 implementation (Weld
> > > Alpha probably) before the spec gets context control? Do they expect to
> > > take their "10k++ class" Java EE applications, throw the EE container
> > > out entirely and run the *unmodified* application in a plain Java SE
> > > environment with CDI SE? Will their apps work even if their
> > > @RequestScoped beans start behaving like singletons?
> > > Probably not, right?
> > >
> > > And then we have early adopters of CDI 2.0. Why should they be exposed
> > > to magical hacks that we know are going to disappear later?
> > >
> > > And let's not forget that:
> > > * CDI implementations already have their own APIs for controlling
> > > contexts that can be used if needed
> > > * A CDI implementation may add such hack by itself - no need to have it
> > > the spec temporarily
> > >
> > > Therefore, I cannot see a single reason for polluting the spec with
> > > temporary hacks.
> > >
> > > Jozef
> > > _______________________________________________
> > > 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.
> >
> > _______________________________________________
> > 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/20150624/70e2bf35/attachment-0001.html 