User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
Thank you Lachlan, that is very comforting.
I looked into this a bit and it looks very promosing. Looking at
WebSocketServlet I conclude (guess...) that I can override
Servlet#service and channel upgrade requests through a separate call
hierarchy like I do with doGet, doPost etc. allowing me to handle
them in a specific type of handler at the place where applications
can create locally embedded WebSocket objects. This also means
Websocket URLs can point directly into the applications and there is
no need for a separate URL prefix like /websocket that puts them out
of context (bad choice of word).
I do not have anything working yet but the weekend is coming up...
Thank you and Joakim for the prompt and helpful responses.
Kind regards,
Silvio
On 1/8/21 4:42 AM, Lachlan Roberts
wrote:
Silvio,
There are no
plans to phase out the Jetty WebSocket API. There have been
recent improvements to the Jetty WebSocket API in the recently
released Jetty10 and Jetty11 versions. It has many advantages
over using the javax.websocket API so there is no reason to
phase it out.
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).
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?
