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.
Cheers,
Lachlan
On Fri, Jan 8, 2021 at 4:49 AM Silvio Bierman
<[email protected] <mailto:[email protected]>> wrote:
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] <mailto:[email protected]>
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jetty-users
<https://www.eclipse.org/mailman/listinfo/jetty-users>
_______________________________________________
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
