Hi,<br><br>On Friday, December 5, 2014, Pavel Bucek &lt;<a href="mailto:pavel.bucek@oracle.com">pavel.bucek@oracle.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">please see inline.<br>
<br>
On 04/12/14 10:04, Martin Kouba wrote:<br>
&gt; Dne 4.12.2014 v 09:28 Pavel Bucek napsal(a):<br>
&gt;&gt; Hello Arjan,<br>
&gt;&gt;<br>
&gt;&gt; On 03/12/14 19:44, arjan tijms wrote:<br>
&gt;&gt;&gt; Hi,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Wednesday, December 3, 2014, Pavel Bucek &lt;<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;pavel.bucek@oracle.com&#39;)">pavel.bucek@oracle.com</a><br>
&gt;&gt;&gt; &lt;mailto:<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;pavel.bucek@oracle.com&#39;)">pavel.bucek@oracle.com</a>&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;      Hi all,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;      I&#39;m trying to figure out how to solve issue in JSR 356 - Java API for<br>
&gt;&gt;&gt;      WebSocket, related to CDI scope usable from WebSocket endpoints.<br>
&gt;&gt;&gt;      Problem<br>
&gt;&gt;&gt;      is, that &quot;standard&quot; scopes do not apply, because there is no<br>
&gt;&gt;&gt;      @RequestScoped (http response is already sent), HttpSession does not<br>
&gt;&gt;&gt;      need to be created and the rest does not seem to be applicable, ...<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;      I believe that CDI specification should define @UpgradeScoped, which<br>
&gt;&gt;&gt;      would cover usages of HttpUpgradeHandler from Servlet API.<br>
&gt;&gt;&gt;      (Similarly as<br>
&gt;&gt;&gt;      it does for @RequestScoped, @SessionScoped, ... )<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Wouldn&#39;t it be a better option to have WebSocket define that scope,<br>
&gt;&gt;&gt; using CDI to implement it?<br>
&gt;&gt; That is one possibility, but @UpgradeScoped would be more general than<br>
&gt;&gt; just for WebSocket - it would apply for all HTTP/1.1+ Upgrade<br>
&gt;&gt; applications. In my eyes, it is something which was forgotten to do in<br>
&gt;&gt; Java EE 7 release, since HttpUpgradeHandler was introduced in it.<br>
&gt;&gt;<br>
&gt;&gt; Also please note, that other Servlet related scopes are already in CDI<br>
&gt;&gt; spec, so it seems like it belongs there more than anywhere else. This<br>
&gt;&gt; might have multiple reasons - for example, you can easily define<br>
&gt;&gt; relationship between @UpgradeScoped and others, already existing ones.<br>
&gt;&gt; In this sense, CDI specification now depends on Servlet API (it<br>
&gt;&gt; references some of the classes defined in it), but Servlet does not do<br>
&gt;&gt; that for CDI. I don&#39;t think that Servlet spec should introduce similar<br>
&gt;&gt; dependency just because of new scope.<br>
&gt; That&#39;s a good point. However, I don&#39;t think it&#39;s a good path to follow.<br>
&gt; I mean if it were in CDI spec, CDI implementations would be required to<br>
&gt; implement this. However, Servlet spec is not very clear in many areas<br>
&gt; and doesn&#39;t always provide a powerful enough SPI. Even now there are<br>
&gt; technical issues with similar requirements (e.g. @RequestScoped during<br>
&gt; AsyncListener invocations). I&#39;m not so sure about HttpUpgradeHandler<br>
&gt; though...<br>
<br>
And what if the @UpgradeScoped definition would need to state something<br>
like &quot;this scope is part of @ApplicationScoped&quot;? That would result even<br>
in more confusion and cross references CDI to Servlet and vice versa.</blockquote><div><br></div><div>I&#39;m not so sure that would necessarily be confusing. If Servlet is &quot;layered&quot; on top of CDI, then a scope in Servlet could reference other things within the Servlet spec, or things in lower layers, which is CDI in this case.</div><div><br></div><div>There would be no cross-references there, would there?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I could see this being part of Servlet spec only if all other<br>
&quot;Servlet-related&quot; scopes are there as well.</blockquote><div><br></div><div>Correct me if I&#39;m wrong, but there&#39;s only one scope in CDI that at the moment exclusively references Servlet, and that&#39;s @SessionScoped.</div><div><br></div><div>Both @RequestScoped and @ApplicationScoped have a (much) broader definition than being just a Servlet scope.</div><div><br></div><div>I&#39;m not entirely sure, but the way these 3 scopes are now set up may not exclude @SessionScoped being applied to other things as well.</div><div><br></div><div>The one problem may be that CDI here lists all other specs that give meaning to the scope. Even though it&#39;s just text and not an actual API dependency, this may not be entirely consistent (but how could it be done better?)</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Con somebody suggest what should I do next? I can file an issue against<br>
CDI spec and even against Servlet spec, but my feeling is that it might<br>
be deferred on both issue trackers as &quot;not in scope, it should be done<br>
somewhere else&quot;. I know I already asked, but - is there any discussion<br>
between CDI and Servlet spec leads about this topic?<br>
<br>
Thanks and regards,<br>
Pavel<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;cdi-dev@lists.jboss.org&#39;)">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" 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 href="http://www.apache.org/licenses/LICENSE-2.0.html" 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>