jetty.project/jetty-websocket
Greg Wilkins a311c8bde1 480904 - jetty-util Loader simplification
The Loader has been simplified to now just be a switch between loading from the context loader,
the same loader as another class or the system loader.    Multiple loaders will never be tried.

A new runWithServerClassAccess(PriviledgedAction) method has been added to WebAppClassLoader, that
is now used during configuration for actions that need access to both the WEB-INF/lib classes and
the server classes (eg jetty-web.xml and env.xml).

The JMX MBean mechanism has also been modified to look for an MBean class in the same loader that
object came from before attempting the context loader (only if different).
2015-11-19 12:14:05 +11:00
..
javax-websocket-client-impl Updating to 9.3.5-SNAPSHOT 2015-10-08 17:49:09 -07:00
javax-websocket-server-impl 481903 Module Descriptions 2015-11-12 10:48:04 +11:00
websocket-api Updating to 9.3.5-SNAPSHOT 2015-10-08 17:49:09 -07:00
websocket-client 480827 Implemented Unix Domain Socket Connector 2015-11-06 11:17:46 +11:00
websocket-common Updating to 9.3.5-SNAPSHOT 2015-10-08 17:49:09 -07:00
websocket-server 480904 - jetty-util Loader simplification 2015-11-19 12:14:05 +11:00
websocket-servlet Updating to 9.3.5-SNAPSHOT 2015-10-08 17:49:09 -07:00
README.TXT renamed README.txt to README.TXT and updated contents 2013-08-29 00:32:36 +10:00
pom.xml Updating to 9.3.5-SNAPSHOT 2015-10-08 17:49:09 -07:00

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.