<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 06/24/2015 11:51 AM, Antoine Sabot-Durand wrote:<br>
<blockquote
cite="mid:CABu-YBRKyr26pWX8oU5eqGKYc2cXd7CtpZkeMCRop5r0H8T07A@mail.gmail.com"
type="cite">
<div dir="ltr">So Jozef,
<div><br>
</div>
<div>1) do you suggest to remove only the request context part
or all chapter 14 (<a moz-do-not-send="true"
href="https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#contexts_se">https://dl.dropboxusercontent.com/u/2898173/cdi-spec.html#contexts_se</a>),
which could make more sense.</div>
</div>
</blockquote>
The request context part.<br>
<blockquote
cite="mid:CABu-YBRKyr26pWX8oU5eqGKYc2cXd7CtpZkeMCRop5r0H8T07A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>2) What will be the request and application context
behavior in the RI?</div>
</div>
</blockquote>
Depends on the spec mostly.<br>
<br>
For the application context it IMHO makes sense to be have a single
storage shared across threads that starts once CDI is booted and
shuts down with it.<br>
<br>
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.<br>
<blockquote
cite="mid:CABu-YBRKyr26pWX8oU5eqGKYc2cXd7CtpZkeMCRop5r0H8T07A@mail.gmail.com"
type="cite"><br>
<div class="gmail_quote">
<div dir="ltr">Le mer. 24 juin 2015 à 11:41, Romain Manni-Bucau
<<a moz-do-not-send="true"
href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">@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.</div>
<div class="gmail_extra"><br clear="all">
<div>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<span style="font-size:small">Romain
Manni-Bucau</span><br>
<a moz-do-not-send="true"
href="https://twitter.com/rmannibucau"
target="_blank">@rmannibucau</a> | <a
moz-do-not-send="true"
href="http://rmannibucau.wordpress.com"
target="_blank">Blog</a> | <a
moz-do-not-send="true"
href="https://github.com/rmannibucau"
target="_blank">Github</a> | <a
moz-do-not-send="true"
href="https://www.linkedin.com/in/rmannibucau"
target="_blank">LinkedIn</a> | <a
moz-do-not-send="true"
href="http://www.tomitribe.com"
target="_blank">Tomitriber</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">2015-06-24 11:39 GMT+02:00 Antoine
Sabot-Durand <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Romain,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div>
<div><br>
<div class="gmail_quote">
<div dir="ltr">Le mer. 24 juin 2015 à 11:31,
Antoine Sabot-Durand <<a
moz-do-not-send="true"
href="mailto:antoine@sabot-durand.net"
target="_blank">antoine@sabot-durand.net</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">Jozef,
<div><br>
</div>
<div>I think I really got your disagreement on
that point. You repeated it many times.</div>
<div><br>
</div>
<div>My point and the question I keep asking
to you is "what is your suggestion?".</div>
<div>Personally I see 5 solutions here:</div>
<div><br>
</div>
<div>1) Don't do anything since there's no
alternative solution</div>
<div>2) Change the wording regarding request
scope activation in something like "is
active from the initialization of the
container until its shutdown"</div>
<div>3) Give the same behavior than
application scope request scope is shared</div>
<div>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</div>
<div>5) Don't specify anything</div>
<div><br>
</div>
<div>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
?</div>
<div><br>
</div>
<div>thanks</div>
</div>
<div dir="ltr">
<div><br>
</div>
<div>Antoine </div>
<div><span
style="line-height:1.5;font-size:13.1999998092651px"> </span><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">Le mer. 24 juin 2015 à 11:13,
Mark Struberg <<a moz-do-not-send="true"
href="mailto:struberg@yahoo.de"
target="_blank">struberg@yahoo.de</a>>
a écrit :<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">Jozef, read the
rest of the meeting minutes as well. Throne
and I enlisted dozen of REAL use cases where
it is needed.<br>
<br>
> Does the @RequestScoped hack really
address customers' problem?<br>
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.<br>
<br>
> * A CDI implementation may add such
hack by itself - no need to have it<br>
> the spec temporarily<br>
Well that is an option but the users then
cannot rely on it.<br>
<br>
<br>
And no, it is perfectly implementable as it
is worded right now.<br>
<br>
LieGrue,<br>
strub<br>
<br>
<br>
> Am 24.06.2015 um 10:50 schrieb Jozef
Hartinger <<a moz-do-not-send="true"
href="mailto:jharting@redhat.com"
target="_blank">jharting@redhat.com</a>>:<br>
><br>
> Hi all,<br>
><br>
> unfortunately I did not make it to the
meeting yesterday. After reading<br>
> the transcript I found out that the
@RequestScoped hack is still being<br>
> added to the EDR. What do I mean by
"@RequestScoped hack"?<br>
> By that I am referring to the following
part of the spec:<br>
><br>
> "<br>
> In Java SE:<br>
> The request scope is active during any
method invocation.<br>
> The request context is destroyed when
the container is shut down.<br>
> "<br>
><br>
> This is vague, almost undefined and not
correctly implementable. Most<br>
> importantly, everyone seems to agree
that it would be a bad idea for<br>
> this to end up in the final spec.
Instead, it is supposed to be replaced<br>
> entirely by ContextControl API (<a
moz-do-not-send="true"
href="https://issues.jboss.org/browse/CDI-530"
rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-530</a>)<br>
> post EDR1.<br>
><br>
> Yet, we are adding this hack to EDR1
for the meantime. Why? The only<br>
> argument to back this was "supporting
existing libraries and applications".<br>
><br>
> That seems reasonable, doesn't it?
Well, no. Antoine took a detailed<br>
> look into probably the most prominent
CDI library - DeltaSpike. Yes, you<br>
> can find @RequestScoped beans in
DeltaSpike. You can find Servlet<br>
> artifact producers, JSF view root and
navigation handlers, etc. And<br>
> that's it. Nothing one could really use
outside of the EE stack.<br>
><br>
> That's not a coincidence. When a user
marks a bean as @RequestScoped we<br>
> can assume they do it for a reason. The
reason most likely would be to<br>
> scope the state per "task" (often HTTP
request processing) and isolate<br>
> the state from the state of other
tasks. That's very different from the<br>
> @Singleton-like behavior that the
@RequestScoped hack adds. Therefore,<br>
> even if a library exists that relies on
@RequestScoped it is not going<br>
> to work properly anyway. The
@RequestScoped hack just suppresses a fast<br>
> failure and trades it for weird state
inconsistencies later.<br>
><br>
> Another part of the argument is
"existing applications". More specifically:<br>
><br>
> "struberg: well, I have a few customers
with 10k++ classes. And some<br>
> core components use it heavily"<br>
><br>
> Does the @RequestScoped hack really
address customers' problem? Remember<br>
> that the @RequestScoped hack is planned
to be temporary and replaced<br>
> with proper context control post EDR1.<br>
> Are those customers planning to migrate
to EDR1 implementation (Weld<br>
> Alpha probably) before the spec gets
context control? Do they expect to<br>
> take their "10k++ class" Java EE
applications, throw the EE container<br>
> out entirely and run the *unmodified*
application in a plain Java SE<br>
> environment with CDI SE? Will their
apps work even if their<br>
> @RequestScoped beans start behaving
like singletons?<br>
> Probably not, right?<br>
><br>
> And then we have early adopters of CDI
2.0. Why should they be exposed<br>
> to magical hacks that we know are going
to disappear later?<br>
><br>
> And let's not forget that:<br>
> * CDI implementations already have
their own APIs for controlling<br>
> contexts that can be used if needed<br>
> * A CDI implementation may add such
hack by itself - no need to have it<br>
> the spec temporarily<br>
><br>
> Therefore, I cannot see a single reason
for polluting the spec with<br>
> temporary hacks.<br>
><br>
> Jozef<br>
>
_______________________________________________<br>
> cdi-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org"
target="_blank">cdi-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this
list, the provider licenses the code under
the Apache License, Version 2 (<a
moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all other ideas provided on this list,
the provider waives all patent and other
intellectual property rights inherent in
such information.<br>
<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org"
target="_blank">cdi-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this
list, the provider licenses the code under
the Apache License, Version 2 (<a
moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all other ideas provided on this list,
the provider waives all patent and other
intellectual property rights inherent in
such information.<br>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/cdi-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the
provider licenses the code under the Apache License,
Version 2 (<a moz-do-not-send="true"
href="http://www.apache.org/licenses/LICENSE-2.0.html"
rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>).
For all other ideas provided on this list, the provider
waives all patent and other intellectual property rights
inherent in such information.<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>