[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Websocket question
|
Thank you again Joakim,
This was exactly what I needed. Being able to handle the upgrade
request inside the main Servlet makes all the difference. We now
have a handler type "Upgrade" that can reside anywhere in the
applications and create locally embedded WebSocket objects with
methods to handle the various events.
Since JSR356 does not seem to specify any similar mechanism our
websocket embedding will probably remain Jetty specific but I am
more than happy with that since I have learned that the Jetty native
websocket interface is not going anywhere. Besides, Jetty has been
our trusted embedded Servlet engine since version 4.x so it is not
like we will be looking to replace Jetty anytime soon.
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).
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
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
