Hi there,
On Thursday, December 4, 2014, Pavel Bucek <pavel.bucek(a)oracle.com> wrote:
Hello Arjan,
On 03/12/14 19:44, arjan tijms wrote:
Hi,
On Wednesday, December 3, 2014, Pavel Bucek <pavel.bucek(a)oracle.com
<javascript:_e(%7B%7D,'cvml','pavel.bucek@oracle.com');>>
wrote:
> Hi all,
>
> I'm trying to figure out how to solve issue in JSR 356 - Java API for
> WebSocket, related to CDI scope usable from WebSocket endpoints. Problem
> is, that "standard" scopes do not apply, because there is no
> @RequestScoped (http response is already sent), HttpSession does not
> need to be created and the rest does not seem to be applicable, ...
>
> I believe that CDI specification should define @UpgradeScoped, which
> would cover usages of HttpUpgradeHandler from Servlet API. (Similarly as
> it does for @RequestScoped, @SessionScoped, ... )
Wouldn't it be a better option to have WebSocket define that scope, using
CDI to implement it?
That is one possibility, but @UpgradeScoped would be more general than
just for WebSocket - it would apply for all HTTP/1.1+ Upgrade applications.
Okay, so in a more broader application than just WebSocket it could be
defined somewhere lower in the spec hierarchy. If it's specific to HTTP
upgrades as you mention, then Servlet may be the next candidate to consider.
In my eyes, it is something which was forgotten to do in Java EE 7
release, since HttpUpgradeHandler was introduced in it.
Also please note, that other Servlet related scopes are already in CDI
spec, so it seems like it belongs there more than anywhere else.
But some of these may not actually belong there. They may have been put
there originally since as a new spec that had yet to be proven, CDI could
not right away ask other specs to support it.
There are discussions going on to move some of the Servlet things from CDI
to Servlet.
This might have multiple reasons - for example, you can easily
define
relationship between @UpgradeScoped and others, already existing ones. In
this sense, CDI specification now depends on Servlet API (it references
some of the classes defined in it), but Servlet does not do that for CDI. I
don't think that Servlet spec should introduce similar dependency just
because of new scope.
There are plenty of other reasons too ;) For Servlet I expect the
dependencies to be optional. Servlet in a EE environment will then provide
scope X & Y, and producers for types Q & R, but it will continue to run
standalone without needing any CDI. In short, it would provides things for
CDI then but in its core wouldn't need CDI.
Just my 2 cents ;)
Thanks,
Pavel