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
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
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
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.
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
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
Hi,
On Mon, Mar 15, 2021 at 12:50 AM Luke B wrote:
>
> Hi,
>
> So it seems conscrypt has even more memory leaks:
> https://github.com/google/conscrypt/issues/835
> https://github.com/google/conscrypt/issues/984
>
> Conscrypt doesn't appear to be sufficiently reliable to be used in production.
>
On 3/14/2021 6:54 PM, Luke B wrote:
Unfortunately my clients want that illusion of safety and it is just
easier to give them that rather than argue with them. I really don't
care to argue this point.
I understand. In the case I dealt with, there are certain companies
that you simply do not
Luke,
That memory leak appears to be on outgoing connection attempts, not
incoming ones. So conscript should be fine for server side usage with
that... or are you also using the client?
As for options to avoid conscript, would offloaded SSL that communicates
via a unix socket rather than
