User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
Thank you Lachlan,
That gets me a bit further. The last parts giving me trouble are the
following methods of the only Servlet class in my aplication (pardon
my Scala, compiler errors inlined with ***prefix)
override def init(cfg : ServletConfig) =
{
_config = cfg
val policy = new WebSocketPolicy(WebSocketBehavior.SERVER)
***trait WebSocketPolicy is abstract; cannot be
instantiated
val ctx = _config.getServletContext
_socketFactory =
WebSocketServletFactory.Loader.load(ctx,policy)
***value Loader is not a member of object
org.eclipse.jetty.websocket.server.JettyWebSocketServletFactory
_socketFactory.setCreator(new SocketCreator())
_socketFactory.start
***value start is not a member of
org.eclipse.jetty.websocket.server.JettyWebSocketServletFactory
ctx.setAttribute(classOf[JettyWebSocketServletFactory].getName,_socketFactory)
}
override def service(request : HttpServletRequest,response :
HttpServletResponse)
{
if (_socketFactory == null) super.service(request,response)
else if (!_socketFactory.isUpgradeRequest(request,response))
super.service(request,response)
***value isUpgradeRequest is not a member of
org.eclipse.jetty.websocket.server.JettyWebSocketServletFactory
else if (!_socketFactory.acceptWebSocket(request,response)
&& !response.isCommitted) super.service(request,response)
***value acceptWebSocket is not a member of
org.eclipse.jetty.websocket.server.JettyWebSocketServletFactory
}
Perhaps you can help me with these last bits?
I do not know if it is relevant at all but I described the context
here earlier. Our application implements a runtime engine for a
dynamic object-functional server side scripting language that
supports HTTP request handler instance methods. Requests are routed
to the corresponding class instances to be handled locally. Such
handler classes can exist at the global application level but can
also be part of session instances. A special type of upgrade handler
method is called to create locally embedded websocket objects with
their own methods to handle the socket events. Since request routing
is done from inside the above service method we need the Jetty API.
All our end user (web-)applications are implemented in the form of
such scripts.
Cheers,
Silvio
On 3/16/21 12:25 AM, Lachlan Roberts
wrote:
Silvio,
The usage of
the Jetty WebSocket API should essentially be the same, but
you will need to update your code to use some of the new
WebSocket classes for Jetty 10. The websocket classes you need
to use for the Jetty WebSocket Server API were previously in
the websocket-servlet jar but are now in the
websocket-jetty-server jar.
Thank you very much for this Greg. No problem for us to
wait a bit longer before moving to Jetty 10 considering 9.4
is serving us as well as it is.
Cheers,
Sillvio
On 3/15/21 6:32 PM, Greg Wilkins wrote:
Silvio,
yes the jetty websocket API has been significantly
revisited in jetty-10. We believe that we have added
significant improvements as a result and have been
waiting for the major release to make such a breaking
change.
We definitely will continue to support our API
going forward, due to deficiencies and complications
of the JSR API. So if your use-case is not already
supported, then we will definitely look to see if we
can. Lachlan Roberts is the lead developer of
websocket now and hopefully will get back to you with
pointers to servlet based upgrade (which I'm 99% sure
is supported).
Some time ago I
extended our embedded Jetty (9.4.36) based server
application to support websockets using the Jetty
websocket API. At this
time we want to revisit our previously successful
efforts making the
application compatible with Jetty 10. But it seems the
websocket API has
changed quite significantly and many of the classes in
org.eclipse.jetty.websocket.servlet and
org.eclipse.jetty.websocket.api
(notably WebSocketServletFactory, WebSocketCreator,
ServletUpgradeRequest and ServletUpgradeResponse)
appear to be missing
or have been moved/renamed. So now we use the
websocket API it appears
porting to Jetty 10 has become much more difficult,
let alone managing a
code-base that allows us to swap one in for the other.
We picked the Jetty websocket API since it allows us
to handle the
request upgrade at the Servlet level (inside the
service method) while
the javax.websocket API upgrades to websockets at the
context level and
is therefore of nu use to us. I hope this is still
possible in the
revised Jetty websocket API but can not find any
documentation about how
to rewrite 9.4.x based code to the new 10.x version.
I can live with not being able to switch back to Jetty
9 without
recompiling.
