I wish this were the case, but it seems that Jetty's WebSocket.onClose method fires even when Jetty closes the WebSocket internally due to some error.
On Fri, Sep 14, 2012 at 1:57 PM, Joakim Erdfelt <[email protected]> wrote: > A websocket.close is a handshake, and the implementation should notify you > when it receives a Close frame. > So it should be safe to assume that if you get onClose, the opposite side > sent it. > > -- > Joakim Erdfelt <[email protected]> > www.webtide.com > Developer advice, services and support > from the Jetty & CometD experts. > > > > On Thu, Sep 13, 2012 at 12:29 PM, Brandon Mintern <[email protected]> > wrote: >> >> Is there a way to determine whether a call to onClose was triggered by >> the client or the server? >> >> I'm implementing a base WebSocket class, and any time a subclass >> throws an exception while handling a message, I close the connection >> with an error message. When this happens, the onClose method fires. >> >> My base WebSocket is providing an onClientClose method to my >> subclasses, so I'd like to know if there's an easy way to determine >> whether a call to onClose was triggered by the Javascript client >> closing the connection or by the Java/jetty server closing the >> connection. Currently, I'm setting a flag before closing the >> connection myself, but I've noticed that any error in jetty also >> closes the connection and calls onClose. >> >> Thanks in advance, >> Brandon >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > _______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
