websocket-spec
  1. websocket-spec
  2. WEBSOCKET_SPEC-240

Support providing endpoint from a container JAR

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      For JSF 2.3 / Mojarra I'm currently in progress of adding a standard <f:websocket> tag. As Mojarra is to be designed as a container-provided JAR (not an user-provided JAR), the endpoint needs to be programmatically added in a ServletContextListener, but at that point, servletContext.getAttribute(ServerContainer.class.getName()) returns null when Tyrus is used (Payara/GlassFish). Upon inspection it turns out that the TyrusServletContainerInitializer#onStartup() immediately returns when there are no user-provided endpoints and doesn't register the ServerContainer anymore, causing it to not be placed in ServletContext anymore. See also https://java.net/jira/browse/TYRUS-420

      I'm therefore making the following proposals to ensure that the websocket container can forcibly be initialized from the container on regardless of the user-provided endpoints.

      1. Proposal #1: require eager initialization.

      • Always initialize container regardless of the onStartup(classes).

      2. Proposal #2: check a context param.

      • Check if a context param something like "javax.websocket.ALWAYS_ENABLED" is set.
      • If so, initialize container regardless of the onStartup(classes).

      3. Proposal #3: check a context attribute.

      • Check if servletContext.getAttribute(ServerContainer.class.getName()) returns null.
      • If so, check if ServerContainer.class.getName() is present in servletContext.getAttributeNames().
      • If so, initialize container regardless of the onStartup(classes).

        Activity

        Hide
        Pavel Bucek added a comment -

        We cannot make any progress without doing Maintenance or Full spec release. Unfortunately, as far as I know, websocket spec is not planned to update in Java EE 8 just yet; as far as I know, websocket spec might do maintenance release if required by Servlet 4 / HTTP 2 integration, but since HTTP 2 / WebSocket relationship is not defined yet...

        Show
        Pavel Bucek added a comment - We cannot make any progress without doing Maintenance or Full spec release. Unfortunately, as far as I know, websocket spec is not planned to update in Java EE 8 just yet; as far as I know, websocket spec might do maintenance release if required by Servlet 4 / HTTP 2 integration, but since HTTP 2 / WebSocket relationship is not defined yet...
        Hide
        arjan tijms added a comment -

        Unfortunately, as far as I know, websocket spec is not planned to update in Java EE 8 just yet;

        I know it's probably not that easy in practice, but would it in any way be possible to start the discussions about planning that update? Thanks!

        Show
        arjan tijms added a comment - Unfortunately, as far as I know, websocket spec is not planned to update in Java EE 8 just yet; I know it's probably not that easy in practice, but would it in any way be possible to start the discussions about planning that update? Thanks!
        Hide
        balusc added a comment - - edited

        Given that you also maintain Tyrus, could you otherwise improve it in Tyrus end? Requesting Tyrus users (GlassFish/Payara users) to manually add a hack in order to use JSF-native websocket support really goes overboard.

        Show
        balusc added a comment - - edited Given that you also maintain Tyrus, could you otherwise improve it in Tyrus end? Requesting Tyrus users (GlassFish/Payara users) to manually add a hack in order to use JSF-native websocket support really goes overboard.
        Hide
        Pavel Bucek added a comment -

        I know it's probably not that easy in practice, but would it in any way be possible to start the discussions about planning that update? Thanks!

        I'm afraid that in this case, it's not up to me/WebSocket spec. You need to talk to JSF spec lead and he needs to convince Java EE architecture group that this update is required / blocking other spec.

        Given that you also maintain Tyrus, could you otherwise improve it in Tyrus end? Requesting Tyrus users (GlassFish/Payara users) to manually add a hack in order to use JSF-native websocket support really goes overboard.

        The general problem with "hacks" like this is that they are not that easy to remove. I very much prefer clean spec-compliant way. (also, just a Tyrus hack doesn't really solve the issue, since JSF doesn't want to depend on Tyrus – the dependency needs to be only on WebSocket spec).

        Show
        Pavel Bucek added a comment - I know it's probably not that easy in practice, but would it in any way be possible to start the discussions about planning that update? Thanks! I'm afraid that in this case, it's not up to me/WebSocket spec. You need to talk to JSF spec lead and he needs to convince Java EE architecture group that this update is required / blocking other spec. Given that you also maintain Tyrus, could you otherwise improve it in Tyrus end? Requesting Tyrus users (GlassFish/Payara users) to manually add a hack in order to use JSF-native websocket support really goes overboard. The general problem with "hacks" like this is that they are not that easy to remove. I very much prefer clean spec-compliant way. (also, just a Tyrus hack doesn't really solve the issue, since JSF doesn't want to depend on Tyrus – the dependency needs to be only on WebSocket spec).
        Hide
        arjan tijms added a comment -

        You need to talk to JSF spec lead and he needs to convince Java EE architecture group that this update is required / blocking other spec.

        Okay, so let's start with that then. Thanks!

        Tyrus hack doesn't really solve the issue, since JSF doesn't want to depend on Tyrus – the dependency needs to be only on WebSocket spec

        Principally true, of course. Mojarra though can depend, more or less, an another GlassFish project if I'm not mistaken. I'm fairly sure that the MVC RI (Ozark) depends on Jersey and does not work out of the box on say JBoss, which uses RestEasy.

        The question is, are we talking about a "hack", or just a proprietary (product specific) way to do something? Hacks should of course be avoided, they indeed don't go away anymore. But a product specific way should not be that bad. There's quite an amount of precedents for that in Java EE. Something gets done in a product specific way first, then if that appears to work it's standardised in a later version of the spec.

        From the JSF side we could maybe look into defining a small SPI for this where we abstract this activation. For GlassFish we then use the Tyrus specific way to activate this, while vendors wishing to combine Mojarra with another WebSocket implementation have to do it in their specific way.

        Would that work for you?

        Show
        arjan tijms added a comment - You need to talk to JSF spec lead and he needs to convince Java EE architecture group that this update is required / blocking other spec. Okay, so let's start with that then. Thanks! Tyrus hack doesn't really solve the issue, since JSF doesn't want to depend on Tyrus – the dependency needs to be only on WebSocket spec Principally true, of course. Mojarra though can depend, more or less, an another GlassFish project if I'm not mistaken. I'm fairly sure that the MVC RI (Ozark) depends on Jersey and does not work out of the box on say JBoss, which uses RestEasy. The question is, are we talking about a "hack", or just a proprietary (product specific) way to do something? Hacks should of course be avoided, they indeed don't go away anymore. But a product specific way should not be that bad. There's quite an amount of precedents for that in Java EE. Something gets done in a product specific way first, then if that appears to work it's standardised in a later version of the spec. From the JSF side we could maybe look into defining a small SPI for this where we abstract this activation. For GlassFish we then use the Tyrus specific way to activate this, while vendors wishing to combine Mojarra with another WebSocket implementation have to do it in their specific way. Would that work for you?

          People

          • Assignee:
            Unassigned
            Reporter:
            balusc
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: