Does the @RequestScoped hack really address customers' problem?

* A CDI implementation may add such hack by itself - no need to have it the spec temporarily

* A CDI implementation may add such hack by itself - no need to have it the spec temporarily

On 06/24/2015 11:10 AM, Mark Struberg wrote: >> 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. 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? > >> * 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. We are talking about an early draft. Users cannot and shouldn't really rely on anything in the draft as chances are it is going to change. _______________________________________________ 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.

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(a)redhat.com&gt;: > > 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(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.

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(a)yahoo.de&gt; 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(a)redhat.com&gt;: > > > > 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(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. >

@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 <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 11:39 GMT+02:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; : > 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(a)sabot-durand.net&gt; 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(a)yahoo.de&gt; 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(a)redhat.com&gt;: >>> > >>> > 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(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. >>> >> > _______________________________________________ > 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. >

So Jozef, 1) do you suggest to remove only the request context part or all chapter 14 (https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#contexts_se), which could make more sense.

2) What will be the request and application context behavior in the RI?

Le mer. 24 juin 2015 à 11:41, Romain Manni-Bucau <rmannibucau(a)gmail.com <mailto:rmannibucau@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 <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 11:39 GMT+02:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@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(a)sabot-durand.net <mailto:antoine@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(a)yahoo.de <mailto:struberg@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(a)redhat.com <mailto:jharting@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(a)lists.jboss.org <mailto:cdi-dev@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 <mailto:cdi-dev@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 <mailto:cdi-dev@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.

Jozef, Sorry my question wasn't precise enough. What will be the Request Context behavior in your implementation of EDR1 ?

Ok, but now in the chapter I have mention for Session Scope and conversation Scope not being active in SE. Wouldn't it be strange to have no mention of Request Scope or should we make a "temp hack" saying that session scope is not active... Le mer. 24 juin 2015 à 16:22, Jozef Hartinger <jharting(a)redhat.com&gt; a écrit : > Depends on the spec mostly. > > For @RequestScoped there is no natural notion of a request in plain Java > SE. It's the user that needs to set the boundaries of a task that the > @RequestScope is supposed to represent. This can be done using Weld API > and hopefully using ContextControl soon. In the meantime I see no point > in blurring this with magical contexts that try to guess what the use > wants. > > That means that the context is not active by default but can be > controlled using the API. > > On 06/24/2015 03:56 PM, Antoine Sabot-Durand wrote: > > Jozef, > > > > Sorry my question wasn't precise enough. What will be the Request > > Context behavior in your implementation of EDR1 ? > >

What happen if we say nothing? will not hurt later IMHO 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 16:28 GMT+02:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>>: Ok, but now in the chapter I have mention for Session Scope and conversation Scope not being active in SE. Wouldn't it be strange to have no mention of Request Scope or should we make a "temp hack" saying that session scope is not active... Le mer. 24 juin 2015 à 16:22, Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@redhat.com>> a écrit : Depends on the spec mostly. For @RequestScoped there is no natural notion of a request in plain Java SE. It's the user that needs to set the boundaries of a task that the @RequestScope is supposed to represent. This can be done using Weld API and hopefully using ContextControl soon. In the meantime I see no point in blurring this with magical contexts that try to guess what the use wants. That means that the context is not active by default but can be controlled using the API. On 06/24/2015 03:56 PM, Antoine Sabot-Durand wrote: > Jozef, > > Sorry my question wasn't precise enough. What will be the Request > Context behavior in your implementation of EDR1 ? _______________________________________________ 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.

I agree. The EDR is supposed to be a draft for review. It’s not supposed to be production ready. Add a note saying “OPEN ISSUE: We need to provide the ability to start the request scope”. In Weld, you can add a release note saying how to do it in Weld. On 24 Jun 2015, at 10:38, Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; wrote: What happen if we say nothing? will not hurt later IMHO 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 16:28 GMT+02:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; : > Ok, but now in the chapter I have mention for Session Scope and > conversation Scope not being active in SE. Wouldn't it be strange to have > no mention of Request Scope or should we make a "temp hack" saying that > session scope is not active... > > Le mer. 24 juin 2015 à 16:22, Jozef Hartinger <jharting(a)redhat.com&gt; a > écrit : > >> Depends on the spec mostly. >> >> For @RequestScoped there is no natural notion of a request in plain Java >> SE. It's the user that needs to set the boundaries of a task that the >> @RequestScope is supposed to represent. This can be done using Weld API >> and hopefully using ContextControl soon. In the meantime I see no point >> in blurring this with magical contexts that try to guess what the use >> wants. >> >> That means that the context is not active by default but can be >> controlled using the API. >> >> On 06/24/2015 03:56 PM, Antoine Sabot-Durand wrote: >> > Jozef, >> > >> > Sorry my question wasn't precise enough. What will be the Request >> > Context behavior in your implementation of EDR1 ? >> >> _______________________________________________ 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.

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(a)gmail.com&gt; 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 <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 11:39 GMT+02:00 Antoine Sabot-Durand <antoine(a)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(a)sabot-durand.net&gt; 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(a)yahoo.de&gt; 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(a)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(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. >>>> >>> >> _______________________________________________ >> 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. >> > >

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(a)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(a)sabot-durand.net&gt;: > 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(a)gmail.com&gt; 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(a)sabot-durand.net&gt;: > 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(a)sabot-durand.net&gt; 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(a)yahoo.de&gt; 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(a)redhat.com&gt;: > > > > 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(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. > > _______________________________________________ > 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. > >