On Mon, Feb 17, 2014 at 10:10 PM, Mack Gerhardt <[email protected]> wrote:
> Is it me or does anyone else feel like the annotation based setup of a > WebSocket pojo is like trying to bring dynamic feel of node and python to > java. Why not have concrete interfaces to implement vs methods to annotate, > and if you screw up the signature it doesn't work as intended vs > implementing an interface and knowing at compile time, and having code > hinting in any ide. > The javadoc for the annotations somewhat spells out what you can and can't do. let me see if I can clarify this a bit... http://docs.oracle.com/javaee/7/api/javax/websocket/OnMessage.html @OnMessage parameter choices (order of parameters is irrelevant): - javax.websocket.Session (optional: [0..1]) http://docs.oracle.com/javaee/7/api/javax/websocket/Session.html - *Basic Websocket Message Type (required: [1] only)* - *TEXT* - *Whole Message Delivery (pick 1)* - java.lang.String - or any javax.websocket.Decoder.Text you have provided http://docs.oracle.com/javaee/7/api/javax/websocket/Decoder.Text.html - *Partial Message Delivery (both must be specified)* - java.lang.String - boolean isLast - *Streaming Delivery (pick 1)* - java.io.Reader - or any javax.websocket.Decoder.TextStream you have provided http://docs.oracle.com/javaee/7/api/javax/websocket/Decoder.TextStream.html - *BINARY* - *Whole Message Delivery (pick 1)* - byte[] - java.nio.ByteBuffer - or any javxx.websocket.Decoder.Binary you have provided http://docs.oracle.com/javaee/7/api/javax/websocket/Decoder.Binary.html - *Partial Message Delivery (boolean plus only 1 data type)* - byte[] - java.nio.ByteBuffer - boolean isLast - *Streaming Delivery (pick 1)* - java.io.InputStream - or any javax.websocket.Decoder.BinaryStream you have provided http://docs.oracle.com/javaee/7/api/javax/websocket/Decoder.BinaryStream.html - *PING/PONG* - javax.websocket.PongMessage (required) http://docs.oracle.com/javaee/7/api/javax/websocket/PongMessage.html - PathParam parameters (optional: [0..n] entries) - This can consist of any java primitives that are also annotated with the @PathParam annotation to indicate what part of the upgrade path is to be reported to the @OnMessage event. So for @OnMessage you can see the following valid method declarations: // first some basic ones void onmessage(String msg) void onmessage(Session session, String msg) void onmessage(String msg, Session session) void onmessage(byte data[]) void onmessage(ByteBuffer data) // here some examples of partial message support void onmessage(String partial, boolean isLast) void onmessage(Session session, ByteBuffer buf, boolean isLast) // heres some Decoder based ones void onmessage(MyData data) // assumes a MyDataDecoder that implements a Decoder type void onmessage(Session session, int value) // part of the JSR spec, and will convert a text message (eg: "123") to an int void onmessage(boolean value) // part of JSR spec, will convert text message (eg:"true") to a boolean // also, here's the return type behavior - returned information will be sent automatically to remote endpoint String onmessage(String msg) byte[] onmessage(ByteBuffer buf) // heres some @PathParam setup void onmessage(ByteBuffer data, @PathParam("gameid") int gameId) // heres a really complex one, using as many features as possible ByteBuffer onmessage(MyGameAction action, Session session, @PathParam("channel") String channel, @Pathparam("gameid") int gameId, @PathParam("spectator") boolean spectator) Once you start to see the multitude of options, you quickly start to realize what the JSR is attempting to do. The return types + @PathParam features are just not present on the extends Endpoint style of use. However, you CAN use the Decoders with the extends Endpoint usage. The JSR-356 spec (as it currently stands) is incomplete, poorly defined, with many vague behaviors (just wait till you get into the Configurators). It has to undergo a revision for any long term success, but so far, there's been little movement in that regard. Since WebSocket (the protocol / RFC-6455) was declared as a message based protocol, not streaming, the various APIs started to fall into line to notify based on messages. If the protocol was streaming based, the APIs would look radically different (or nothing new at all, but merely use URLSocketConnection or something similar). > > One of the things I love about java is the rigidity, and that it is not > dynamic, and I can reflect over classes, and methods. It just feels like > they are trying to do cool things with jsr-356, instead of a nice clean api. > This is the trend, unfortunately. Annotate everything, bind nothing in code, let the runtime figure it out. - Joakim
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
