<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    The way I found to integrate WebSockets with other technologies, is
    by using CDI Events.<br>
    <br>
    I've blogged about it here (integration between WS and JMS): <br>
    -
<a class="moz-txt-link-freetext" href="https://blogs.oracle.com/brunoborges/entry/integrating_websockets_and_jms_with">https://blogs.oracle.com/brunoborges/entry/integrating_websockets_and_jms_with</a><br>
    <br>
    I've also played around with JAX-RS 2.0 (receiving @GET messages and
    sending to WS endpoints using CDI Events).<br>
    <br>
    IMO, this is great and works fine, but does not remove the need for
    a @MessageScope or some other fix in the WS spec, or the CDI spec.<br>
    <br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 05/26/2013 05:24 AM, Mark Struberg
      wrote:<br>
    </div>
    <blockquote
      cite="mid:1369556690.90981.YahooMailNeo@web28905.mail.ir2.yahoo.com"
      type="cite">
      <pre wrap="">Hi!

A user can easily use CDI in WebSocket apps already via DeltaSpike ContextControl. Even if the container does not yet support it.


LieGrue,
strub





----- Original Message -----
</pre>
      <blockquote type="cite">
        <pre wrap="">From: Pete Muir <a class="moz-txt-link-rfc2396E" href="mailto:pmuir@bleepbleep.org.uk">&lt;pmuir@bleepbleep.org.uk&gt;</a>
To: <a class="moz-txt-link-rfc2396E" href="mailto:cdi-dev@lists.jboss.org">"cdi-dev@lists.jboss.org"</a> <a class="moz-txt-link-rfc2396E" href="mailto:cdi-dev@lists.jboss.org">&lt;cdi-dev@lists.jboss.org&gt;</a>
Cc: 
Sent: Wednesday, 22 May 2013, 12:15
Subject: [cdi-dev] Fwd: [jsr342-experts] request scope for Web Sockets?

All, please see below, and let me know your thoughts.

I would prefer to see the Web Sockets spec handle this, just like we had JTA 
handle the TransactionScoped context details.

Begin forwarded message:

</pre>
        <blockquote type="cite">
          <pre wrap=""> From: Bill Shannon <a class="moz-txt-link-rfc2396E" href="mailto:bill.shannon@oracle.com">&lt;bill.shannon@oracle.com&gt;</a>
 Subject: [jsr342-experts] request scope for Web Sockets?
 Date: 16 May 2013 19:21:40 BST
 To: <a class="moz-txt-link-abbreviated" href="mailto:jsr342-experts@javaee-spec.java.net">jsr342-experts@javaee-spec.java.net</a>
 Cc: Joseph Snyder <a class="moz-txt-link-rfc2396E" href="mailto:J.J.SNYDER@oracle.com">&lt;J.J.SNYDER@oracle.com&gt;</a>, Danny Coward 
</pre>
        </blockquote>
        <pre wrap=""><a class="moz-txt-link-rfc2396E" href="mailto:danny.coward@oracle.com">&lt;danny.coward@oracle.com&gt;</a>, Rajiv Mordani <a class="moz-txt-link-rfc2396E" href="mailto:Rajiv.Mordani@oracle.com">&lt;Rajiv.Mordani@oracle.com&gt;</a>, 
"CHAN,SHING WAI" <a class="moz-txt-link-rfc2396E" href="mailto:shing.wai.chan@oracle.com">&lt;shing.wai.chan@oracle.com&gt;</a>
</pre>
        <blockquote type="cite">
          <pre wrap=""> Reply-To: <a class="moz-txt-link-abbreviated" href="mailto:jsr342-experts@javaee-spec.java.net">jsr342-experts@javaee-spec.java.net</a>

 Experts,

 An issue has come up about the definition of the CDI request scope and how
 it applies to Web Sockets applications.&nbsp; The issue is reported here:
 <a class="moz-txt-link-freetext" href="https://issues.jboss.org/browse/CDI-370">https://issues.jboss.org/browse/CDI-370</a>

 We're trying to decide whether this is a simple oversight that could be
 corrected with an errata to the existing spec(s), or whether it's a 
</pre>
        </blockquote>
        <pre wrap="">missing
</pre>
        <blockquote type="cite">
          <pre wrap=""> requirement that would require a new revision of the spec(s).&nbsp; Since this
 involves the interaction of three specs, I'm starting the conversation 
</pre>
        </blockquote>
        <pre wrap="">here.
</pre>
        <blockquote type="cite">
          <pre wrap="">
 Danny, Pete, Shing Wai, please forward this message to your expert groups
 for their input as well.


 Here's the definition of when a request scope is active and when it is 
</pre>
        </blockquote>
        <pre wrap="">destroyed:
</pre>
        <blockquote type="cite">
          <pre wrap="">
</pre>
          <blockquote type="cite">
            <pre wrap=""> The request scope is active:

&nbsp; &nbsp; - during the service() method of any servlet in the web
&nbsp; &nbsp; &nbsp; application, during the doFilter() method of any servlet filter 
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">and
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">&nbsp; &nbsp; &nbsp; when the container calls any ServletRequestListener or 
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">AsyncListener,
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">&nbsp; &nbsp; - during any Java EE web service invocation,
&nbsp; &nbsp; - during any remote method invocation of any EJB, during any
&nbsp; &nbsp; &nbsp; asynchronous method invocation of any EJB, during any call to an 
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">EJB
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">&nbsp; &nbsp; &nbsp; timeout method and during message delivery to any EJB 
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">message-driven
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">&nbsp; &nbsp; &nbsp; bean, and
&nbsp; &nbsp; - during any message delivery to a MessageListener for a JMS
&nbsp; &nbsp; &nbsp; topic or queue obtained from the Java EE component environment.

 The request context is destroyed:

&nbsp; &nbsp; - at the end of the servlet request, after the service() method, all
&nbsp; &nbsp; &nbsp; doFilter() methods, and all requestDestroyed() and onComplete()
&nbsp; &nbsp; &nbsp; notifications return,
&nbsp; &nbsp; - after the web service invocation completes,
&nbsp; &nbsp; - after the EJB remote method invocation, asynchronous method 
</pre>
          </blockquote>
        </blockquote>
        <pre wrap="">invocation,
</pre>
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">&nbsp; &nbsp; &nbsp; timeout or message delivery completes, or
&nbsp; &nbsp; - after the message delivery to the MessageListener completes.
</pre>
          </blockquote>
          <pre wrap="">
 It would be easy to "fix" the first bullet in each list above by 
</pre>
        </blockquote>
        <pre wrap="">saying
</pre>
        <blockquote type="cite">
          <pre wrap=""> "oops, we forgot to include the work done by a protocol handler in
 Servlet 3.1".&nbsp; Since all this other work done by Servlet applications
 is part of the same request scope, adding the work done by protocol
 handlers would make sense.

 But, we have to decide if that's the fix we want.

 Adding bullet items to each list to cover specific Web Socket operations
 might be more what people are expecting, resulting in a request scope for
 Web Sockets that's "smaller" than the request scope for the 
</pre>
        </blockquote>
        <pre wrap="">corresponding
</pre>
        <blockquote type="cite">
          <pre wrap=""> http request.&nbsp; Even if we did that, we would still need to define clearly
 whether or not a request scope is active during any arbitrary protocol
 handler operation (not just Web Socket protocol handlers).&nbsp; Defining it
 for Web Sockets but not defining it for protocol handlers in general might
 be acceptable.&nbsp; Defining it one way for Web Sockets and a different way
 for other protocol handlers would not be acceptable.


 Should we fix this as an errata by saying that obviously protocol handler
 operations should've been included in those lists of Servlet 
</pre>
        </blockquote>
        <pre wrap="">operations?
</pre>
        <blockquote type="cite">
          <pre wrap="">
 Or should we add items to each list to cover specifically Web Socket
 operations?&nbsp; (In which case what do we say about protocol handlers in
 general?)&nbsp; This would clearly require a new version of either the CDI
 spec or the Web Sockets spec.

 If we defined all Web Socket operations for a single http request to be
 part of the same request scope (the "errata" approach), we could 
</pre>
        </blockquote>
        <pre wrap="">later
</pre>
        <blockquote type="cite">
          <pre wrap=""> define a "message" scope or something similar to cover individual 
</pre>
        </blockquote>
        <pre wrap="">Web Socket
</pre>
        <blockquote type="cite">
          <pre wrap=""> operations.

 Let us know what you think.
</pre>
        </blockquote>
        <pre wrap="">

_______________________________________________
cdi-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>

</pre>
      </blockquote>
      <pre wrap="">
_______________________________________________
cdi-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/cdi-dev">https://lists.jboss.org/mailman/listinfo/cdi-dev</a>
</pre>
    </blockquote>
    <br>
    <div class="moz-signature">--
      <pre><code>Bruno Borges (twitter @brunoborges)
Principal Product Manager | Java WebLogic Coherence GlassFish
Oracle LAD PM Team        | Cloud Application Foundation
+55 11 5187 6514 (Work)   | +55 11 99564 9058 (Mobi)</code></pre>
    </div>
  </body>
</html>