Thank you, that sounds interesting. I will look into this. I have one
question though about the status of the Jetty WebSocket API: will that
be supported for coming Jetty versions or will it eventually be phased
out in favor of javax.websocket API?
Kind regards,
Silvio
On 1/7/21 6:12 PM, Joakim Erdfelt wrote:
The WebSocket upgrade is typically done before anything else.
That includes cookie management, authentication, parameter handling,
content-type handling, content-encoding handling, etc ...
Typically, the WebSocket upgrade is done via a WebSocketUpgradeFilter
(which sits first in line of the filter chain).
But in your specific case, I would recommend NOT using javax.websocket
API, and use the Jetty WebSocket API instead.
Register your own custom WebSocketCreator implementation that works
within your web app.
That way you are in (limited) control over what the upgrade does.
I say limited, as there are many things not supported during the
websocket upgrade handshake, and using the WebSocketCreator handles
much of that for you (eg: many standard HTTP Response headers are
forbidden during websocket upgrade).
To use this, you would continue to use the WebSocketUpgradeFilter and
add path mappings to your custom creator (be it Servlet url-pattern,
or Regex, and even Uri Template path mappings).
Joakim Erdfelt / [email protected] <mailto:[email protected]>
On Thu, Jan 7, 2021 at 10:37 AM Silvio Bierman
<[email protected] <mailto:[email protected]>> wrote:
Hello all,
I have been experimenting with the JSR 356 Websocket support in Jetty
using WebSocketServerContainerInitializer. Although the API is pretty
clean and simple it is not a good match for my embedded Jetty
application model since requests are being promoted to socket class
instances at the context level.
The application (embedded Jetty) uses one context with one Servlet
singleton and dispatches all messages through a complicated hierarchy
into scripts (which are custom language applications) and inside
these
scripts into object instances containing handlers. HTTP Sessions are
also mapped onto object instances that either handle session local
requests themselves or contain other objects that handle their own
requests. This way URLs address specific parts of a specific
applications and the requests are handled inside the local object
state/scope of the handler objects.
Adding Websockets to this application model would be extremely more
elegant if I could dispatch/handle the initial HTTP request as a
regular
request (through the Servlet singleton) and then promote the
request to
a socket class instance inside the local scopes myself. Is that at
all
possible? And if so, will I have to do everything myself or is it
still
possible to use most/part of the Jetty Websocket embedding?
Any pointers will be very much appreciated.
Kind regards,
Silvio
_______________________________________________
jetty-users mailing list
[email protected] <mailto:[email protected]>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
<https://www.eclipse.org/mailman/listinfo/jetty-users>
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
