8f383faf78
* Issue #3872 Javax Websocket Packaging Moved JaxaxWebSocketConfiguration and SCI to config package. Limited classpath exposure in JavaxConfiguration (more needed) Updated tests with work around for those that needs more classes exposed Signed-off-by: Greg Wilkins <gregw@webtide.com> * Issue #3872 Javax Websocket Packaging Moved all remaining classes from org.eclipse.jetty.websocket.javax.server to org.eclipse.jetty.websocket.javax.server.internal. This works when running on the classpath, but the tests fail when running on the modulepath (eg in commandline mvn run). The issue appears to be that the tests don't load test classes from WEB-INF/lib or WEB-INF/classes. Instead the test classes were themselves in org.eclipse.jetty.websocket.javax.server, which is no longer exported from module-info.java. The hacked "fix" for this has been to create a org.eclipse.jetty.websocket.javax.server.tests package which is exported and to move all the tests to that. A better fix is needed. Signed-off-by: Greg Wilkins <gregw@webtide.com> * Issue #3872 Javax Websocket Packaging improve comments tighten exposed classes more Signed-off-by: Greg Wilkins <gregw@webtide.com> * Issue #3872 - fixing tests Signed-off-by: Lachlan Roberts <lachlan@webtide.com> * Issue #3872 - move ContainerDefaultConfigurator to config package Signed-off-by: Lachlan Roberts <lachlan@webtide.com> * Issue #3873 - fix javax websocket test classloader issues move websocket endpoints for test webapps to com.acme.websocket package Signed-off-by: Lachlan Roberts <lachlan@webtide.com> |
||
|---|---|---|
| .. | ||
| javax-websocket-client | ||
| javax-websocket-common | ||
| javax-websocket-server | ||
| javax-websocket-tests | ||
| jetty-websocket-api | ||
| jetty-websocket-client | ||
| jetty-websocket-common | ||
| jetty-websocket-server | ||
| jetty-websocket-tests | ||
| websocket-core | ||
| websocket-servlet | ||
| README.TXT | ||
| pom.xml | ||
README.TXT
This is the jetty websocket module that provides a websocket server and the skeleton of a websocket client.
By default websockets is included with a jetty release (with these classes either being in the jetty-websocket jar or in
an aggregate jar (see below).
In order to accept a websocket connection, the websocket handshake request is first routed to normal HTTP request
handling, which must respond with a 101 response and an instance of WebSocketConnection set as the
"org.eclipse.jetty.io.Connection" request attribute. The accepting behaviour is provided by WebSocketHandler or the
WebSocketServlet class, both of which delegate to the WebSocketFactory class.
A TestServer and TestClient class are available, and can be run either directly from an IDE (if jetty source is
imported), or from the command line with
java -cp jetty-aggregate/jetty-all/target/jetty-all-7.x.y.jar:jetty-distribution/target/distribution/lib/servlet-api-2.5.jar
org.eclipse.jetty.websocket.TestServer --help
java -cp jetty-aggregate/jetty-all/target/jetty-all-7.x.y.jar:jetty-distribution/target/distribution/lib/servlet-api-2.5.jar
org.eclipse.jetty.websocket.TestClient --help
Without a protocol specified, the client will just send/receive websocket PING/PONG packets. A protocol can be specified for testing other
aspects of websocket. Specifically the server and client understand the following protocols:
org.ietf.websocket.test-echo
Websocket messages are sent by the client and the server will echo every frame.
org.ietf.websocket.test-echo-broadcast
Websocket messages are sent by the client and the server will echo every frame to every connection.
org.ietf.websocket.test-echo-assemble
Websocket messages are sent by the client and the server will echo assembled messages as a single frame.
org.ietf.websocket.test-echo-fragment
Websocket messages are sent and the server will echo each message fragmented into 2 frames.