Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Websocket Configuration

    Is there any documentation on setting up websockets for the messaging library? I have the messaging library working, but I'm assuming it's falling back to another mechanism. I'm getting 404 errors when messaging tries to connect:

    Code:
    [WARN] 404 - GET /.../sc/websocket?ts=1568033891125...

    #2
    The websocket auto-registers and is supposed to work without configuration, but by default at /isomorphic/websocket. You can change this by overriding this property in your server.properties:

    Code:
    [messaging.websocket.URI: /isomorphic/websocket
    Can you change this to your /.../sc/websocket URI and see if that works? If so, then we just have a bug with SGWT auto-registration using the wrong URI.

    Comment


      #3
      So that got a little better I added this to my server.properties (the leading forward slash being important):

      Code:
      messaging.websocket.URI:/$gwtModuleName/sc/websocket
      That gets rid of the websocket 404 error, however now I'm getting this in the server logs:

      Code:
      2019-09-10T17:55:38.498Z [] ERROR (qtp721800657-97) com.isomorphic.js.JSTranslater [c.i.j.JSTranslater(error:56)] parse failure: 
      java.lang.ClassCastException: com.isomorphic.js.parser.JSParser cannot be cast to com.isomorphic.interfaces.IJSParser
      2019-09-10T17:55:38.498Z [] ERROR (qtp721800657-97) com.isomorphic.messaging.MessagingWebSocketEndpoint [c.i.m.MessagingWebSocketEndpoint(error:61)] Failure in onMessage handler
      com.isomorphic.js.UnconvertableException: parse failure: 
      java.lang.ClassCastException: com.isomorphic.js.parser.JSParser cannot be cast to com.isomorphic.interfaces.IJSParser
          at com.isomorphic.js.JSTranslater.fromJS(JSTranslater.java:2192)
          at com.isomorphic.js.JSTranslater.fromJS(JSTranslater.java:2176)
          at com.isomorphic.messaging.MessagingWebSocketEndpoint$ISCMessageHandler.onMessage(MessagingWebSocketEndpoint.java:164)
          at com.isomorphic.messaging.MessagingWebSocketEndpoint$ISCMessageHandler.onMessage(MessagingWebSocketEndpoint.java:148)
          at org.eclipse.jetty.websocket.jsr356.messages.TextWholeMessage.messageComplete(TextWholeMessage.java:56)
          at org.eclipse.jetty.websocket.jsr356.endpoints.JsrEndpointEventDriver.onTextFrame(JsrEndpointEventDriver.java:218)
          at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.incomingFrame(AbstractEventDriver.java:161)
          at org.eclipse.jetty.websocket.common.WebSocketSession.incomingFrame(WebSocketSession.java:308)
          at org.eclipse.jetty.websocket.common.extensions.ExtensionStack.incomingFrame(ExtensionStack.java:214)
          at org.eclipse.jetty.websocket.common.Parser.notifyFrame(Parser.java:220)
          at org.eclipse.jetty.websocket.common.Parser.parse(Parser.java:258)
          at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.readParse(AbstractWebSocketConnection.java:632)
          at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:480)
          at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
          at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
          at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
          at java.lang.Thread.run(Thread.java:748)
      Caused by: java.lang.ClassCastException: com.isomorphic.js.parser.JSParser cannot be cast to com.isomorphic.interfaces.IJSParser
          at com.isomorphic.js.JSTranslater.fromJS(JSTranslater.java:2186)
          ... 16 common frames omitted

      Comment


        #4
        Which version of SGWT are you using and do you have isomorphic_js_parser.jar in your WEB-INF/lib?

        Comment


          #5
          I verified that the js_parser jar is present in the lib folder. I'm using version:

          Code:
          Isomorphic SmartClient/SmartGWT Framework (v12.0p_2019-08-07/Enterprise Deployment 2019-08-07)

          Comment


            #6
            Hey - did you ever resolve this? The error is odd on the face of it because a JSParser is definitely an IJSParser and the line of code implies that our reflection based loader failed while instantiating what is definitely the correct class.

            The only way I can see this could happen is if there is a another isomorphic_js_parser.jar somewhere were it would appear in the CLASSPATH before the assets in WEB-INF/lib _and_ that it would be loaded by a different classloader. Maybe the core jetty libs dir?

            Comment


              #7
              Nope, same issue.

              I verified my classpath when this starts from my IDE as well as the libs in the WEB-INF/lib folder. There aren't any duplicated jars.

              Since I was just running this from superdevmode, I did want to point out that I added the following to my pom.xml to have Jett's websocket libs included:

              Code:
                      <dependency>
                          <groupId>org.eclipse.jetty.websocket</groupId>
                          <artifactId>websocket-server</artifactId>
                          <version>${sdm.jetty.version}</version>
                          <scope>provided</scope>
                      </dependency>
                      <dependency>
                          <groupId>org.eclipse.jetty.websocket</groupId>
                          <artifactId>javax-websocket-server-impl</artifactId>
                          <version>${sdm.jetty.version}</version>
                          <scope>provided</scope>
                      </dependency>
                      <dependency>
                          <groupId>javax.websocket</groupId>
                          <artifactId>javax.websocket-api</artifactId>
                          <version>1.1</version>
                          <scope>provided</scope>
                      </dependency>

              Comment


                #8
                Couple of things to try:

                1. Remove those dependencies from pom.xml and instead tell jetty to enable the websocket module as described here: https://www.eclipse.org/jetty/docume...abling-modules

                2. Try flipping parentLoaderPriority to true as described here: https://www.eclipse.org/jetty/docume...ssloading.html

                Comment


                  #9
                  I'll give your suggestions a try when I get some time to circle back to this issue. However, enabling modules I don't think is possible running on GWT's embedded Jetty server. Is the Isomorphic team able to use messaging while running in GWT's superdevmode?

                  Testing/developing using the Messages framework will be incredibly difficult if I can't get it to run using superdevmode.

                  Comment


                    #10
                    Yes, we can test modules using SuperDevMode.

                    What do you mean by "enabling modules I don't think is possible running on GWT's embedded Jetty server"?

                    If you mean that client-side includes (like ISC_Messaging.js) don't automatically happen, you just include them yourself - this and other approaches are covered in our Debugging overview.

                    Comment


                      #11
                      I was referring to Jetty modules. The article you linked, adding websocket module like:

                      Code:
                      java -jar $JETTY_HOME/start.jar --add-to-start=websocket
                      How would I do that when running embedded Jetty from superdevmode? Is there anything I would have to do/pass to superdevmode to enable websockets?

                      Comment


                        #12
                        Customizing the built-in GWT Jetty server may not be easy. Apparently, it was simpler in GWT 2.5.1, but not in later versions, as is reported here. Official guidance from GWT according to threads like this one is to just switch to your own server rather than using the built-in one.

                        Comment

                        Working...
                        X