Silvio,
The standard way to upgrade to websocket in Jetty is to register a mapping
with the JettyWebSocketServlet or with the WebSocketUpgradeFilter.
If you don't want to register a mapping and want to programmatically
upgrade then you will need to use the `upgrade` method on the
JettyWebSocketServerContainer.
Here is an example of this:
```
public class WebSocketProgrammaticUpgradeServlet extends HttpServlet
{
private JettyWebSocketServerContainer container;
private JettyWebSocketCreator creator;
@Override
public void init(ServletConfig config) throws ServletException
{
container =
JettyWebSocketServerContainer.getContainer(config.getServletContext());
creator = new SocketCreator();
super.init(config);
}
@Override
protected void service(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException
{
// This will return true if the connection has been upgraded to
websocket.
if (container.upgrade(creator, request, response))
return;
if (response.isCommitted())
return;
super.service(request,response);
}
}
```
Cheers,
Lachlan
On Tue, Mar 16, 2021 at 11:31 AM Silvio Bierman <sbier...@jambo-software.com>
wrote:
> 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.
>
> == Classes Renamed ==
> WebSocketCreator -> JettyWebSocketCreator
> ServletUpgradeRequest -> JettyServerUpgradeRequest
> ServletUpgradeResponse -> JettyServerUpgradeResponse
> WebSocketServlet -> JettyWebSocketServlet
> WebSocketServletFactory -> JettyWebSocketServletFactory
>
> == Package Change for these Classes ==
> org.eclipse.jetty.websocket.servlet -> org.eclipse.jetty.websocket.server
>
> Cheers,
> Lachlan
>
> On Tue, Mar 16, 2021 at 5:00 AM Silvio Bierman <
> sbier...@jambo-software.com> wrote:
>
>> 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).
>>
>> cheers
>>
>>
>>
>>
>>
>>
>> On Mon, 15 Mar 2021 at 18:25, Silvio Bierman <sbier...@jambo-software.com>
>> wrote:
>>
>>> 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.
>>>
>>> Can anyone give me some pointers?
>>>
>>> Kind regards,
>>>
>>> Silvio
>>> _______________________________________________
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>
>>
>>
>> --
>> Greg Wilkins <gr...@webtide.com> CTO http://webtide.com
>>
>> _______________________________________________
>> jetty-users mailing listjetty-us...@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
>>
>> _______________________________________________
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
>
> _______________________________________________
> jetty-users mailing listjetty-us...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
>
> _______________________________________________
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
