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, ... )

What are your thoughts about this? Thanks and regards, Pavel _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org <javascript:;> 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.

Hi, On Wednesday, December 3, 2014, Pavel Bucek <pavel.bucek(a)oracle.com <mailto: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?

Dne 4.12.2014 v 09:28 Pavel Bucek napsal(a): > Hello Arjan, > > On 03/12/14 19:44, arjan tijms wrote: >> Hi, >> >> On Wednesday, December 3, 2014, Pavel Bucek <pavel.bucek(a)oracle.com >> <mailto: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. 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. 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. That's a good point. However, I don't think it's a good path to follow. I mean if it were in CDI spec, CDI implementations would be required to implement this. However, Servlet spec is not very clear in many areas and doesn't always provide a powerful enough SPI. Even now there are technical issues with similar requirements (e.g. @RequestScoped during AsyncListener invocations). I'm not so sure about HttpUpgradeHandler though...

On Friday, December 5, 2014, Pavel Bucek <pavel.bucek(a)oracle.com <mailto:pavel.bucek@oracle.com>> wrote: On 04/12/14 10:04, Martin Kouba wrote: > Dne 4.12.2014 v 09:28 Pavel Bucek napsal(a): >> >> On 03/12/14 19:44, arjan tijms wrote: >>> >>> On Wednesday, December 3, 2014, Pavel Bucek <pavel.bucek(a)oracle.com <javascript:;> >>> <mailto:pavel.bucek@oracle.com <javascript:;>>> wrote: >>> >>> 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. 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. 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. > That's a good point. However, I don't think it's a good path to follow. > I mean if it were in CDI spec, CDI implementations would be required to > implement this. However, Servlet spec is not very clear in many areas > and doesn't always provide a powerful enough SPI. Even now there are > technical issues with similar requirements (e.g. @RequestScoped during > AsyncListener invocations). I'm not so sure about HttpUpgradeHandler > though... And what if the @UpgradeScoped definition would need to state something like "this scope is part of @ApplicationScoped"? That would result even in more confusion and cross references CDI to Servlet and vice versa. I'm not so sure that would necessarily be confusing. If Servlet is "layered" 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. There would be no cross-references there, would there?

I could see this being part of Servlet spec only if all other "Servlet-related" scopes are there as well. Correct me if I'm wrong, but there's only one scope in CDI that at the moment exclusively references Servlet, and that's @SessionScoped. Both @RequestScoped and @ApplicationScoped have a (much) broader definition than being just a Servlet scope. I'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.

The one problem may be that CDI here lists all other specs that give meaning to the scope. Even though it's just text and not an actual API dependency, this may not be entirely consistent (but how could it be done better?)

Kind regards, Arjan Tijms Con somebody suggest what should I do next? I can file an issue against CDI spec and even against Servlet spec, but my feeling is that it might be deferred on both issue trackers as "not in scope, it should be done somewhere else". I know I already asked, but - is there any discussion between CDI and Servlet spec leads about this topic? Thanks and regards, Pavel _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org <javascript:;> 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.

Hi, On Mon, Dec 8, 2014 at 3:50 PM, Pavel Bucek <pavel.bucek(a)oracle.com&gt; wrote: >> I'm not so sure that would necessarily be confusing. If Servlet is "layered" >> 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. >> There would be no cross-references there, would there? > well.. I'm not the expert in Servlet nor CDI spec, but what I see in Servlet > is NOT related to CDI directly. Simple search does not include any > "RequestScoped" appearance. No, but the idea is that if Servlet would make use of CDI, then there still would be no cross-references. If the @UpgradeScoped would be in Servlet, then it could reference things in either Servlet (=same layer) or in CDI (one layer lower). In that case, independent of whether any scope would move from CDI to Servlet, or whether those scopes will stay in CDI, there will be no cross-references. > So, from my point of view, Servlet DOES NOT depend on CDI. It doesn't, but who ever said that it does at the moment?

>> The one problem may be that CDI here lists all other specs that give meaning >> to the scope. Even though it's just text and not an actual API dependency, >> this may not be entirely consistent (but how could it be done better?) > > That is not exactly correct - CDI spec defines how these scopes should be > implemented - it *gives* the meaning to the scopes (at least in this case) > in other specifications (see my note about no @*Scoped references in Servlet > spec). Well, it defines when the scope should be active for each spec, but what I meant is that the actual implementation of what the scope means is in the other spec. E.g. @RequestScope says it's active: "during any remote method invocation of any EJB" Naturally, what the time during a "remote method invocation of any EJB" is, is defined in the EJB spec. CDI just says this scope should match that, but it doesn't say what an EJB is, and what a "remote method invocation" exactly is. Eventually it's an architectural decision; should CDI have knowledge of all other specs and depend on events or hooks in those specs to do what I needs to do, OR should CDI be more about a lower level set of primitive functionality that is used by all other specs? We now unfortunately have both situations. JSF has scopes like @ViewScoped and @FlowScoped that USE CDI. JSF will get producers for several artefacts that USE CDI. CDI in those cases does not know JSF. JTA has an interceptor @Transactional that USES CDI. In this case, CDI does not know JTA. On the other hand, CDI has scopes like @RequestScoped that references Servlet, Web Services, EJB and JMS. Here, Servlet, Web Services etc do not know CDI. CDI also has producers for several types like HttpServletRequest (Servlet), Principal (technically JASPIC but can also be Servlet proprietary) and UserTransaction (JTA). Here, Servlet, JASPIC and JTA do not know CDI. Especially for the producers it seems rather random of when it appears in CDI, and when it appears in the spec that owns the produced artefacts. As mentioned, the 3 scopes in CDI are somewhat more complicated as at least two of them are broadly applicable. Should CDI continue to define them, or should CDI give a very general description, with the more specific description being given by each spec itself? I don't really know what's best there.

Hi FYI we are hoping to have no Servlet related topics in the CDI 2.0 specification. The idea is for other specifications to use CDI to create their own scope (@ViewScoped/@FlowScoped in JSF, but also @TransactionScoped in JTA). Following this logic, the @UpgradeScoped would make sense in the WebSocket spec. Antonio On Thu, Dec 4, 2014 at 9:28 AM, Pavel Bucek <pavel.bucek(a)oracle.com <mailto:pavel.bucek@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 <mailto: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. 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. 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. Thanks, Pavel _______________________________________________ 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. -- Antonio Goncalves Software architect, Java Champion and Pluralsight author Web site <http://www.antoniogoncalves.org> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>

Hi there, On Thursday, December 4, 2014, Pavel Bucek <pavel.bucek(a)oracle.com <mailto:pavel.bucek@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 ;)