Re: [jetty-users] Jetty 10 websocket API changes

[Lachlan Roberts]

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 
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 

Re: [jetty-users] Jetty 10 websocket API changes

[Silvio Bierman]

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 
mailto: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
mailto: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 

Re: [jetty-users] Jetty 10 websocket API changes

[Lachlan Roberts]

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 
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 
> 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  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 list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Jetty 10 websocket API changes

[Silvio Bierman]

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 
mailto: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 mailto:gr...@webtide.com>> CTO 
http://webtide.com 


___
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

Re: [jetty-users] Jetty 10 websocket API changes

[Greg Wilkins]

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 
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  CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

[jetty-users] Jetty 10 websocket API changes

[Silvio Bierman]

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

Re: [jetty-users] Fast SSL with jetty.

[Simone Bordet]

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.
>
> Setting up jetty to listen only on localhost without SSL and having an nginx 
> (or other web server) reverse proxy to provide SSL is possible but unlikely 
> something that is acceptable as encryption is required all the way to the 
> java process. In this case a tcp dump would reveal passwords.
>
> Jetty, it seems, is trapped behind Java's relatively slow SSL implementation.

I guess the keyword here is "relatively".

Java's SSL is slower no doubt, but perhaps it does the job?
Is the move to Conscrypt due to benchmarks (A is faster than B), but B
can handle the load just nicely?
Is the move to Conscrypt due to saving CPU/memory in the cloud to save money?

I'm saying that with the latest Java versions, with native support for
encryption primitives, TLS resumption, etc. maybe Java TLS does the
job for you.
Sure it's not the Ferrari you wanted, but it's a decently fast car anyway?

-- 
Simone Bordet

http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Fast SSL with jetty.

[Shawn Heisey]

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 say no to, not if you want their deep pockets. 
I'm not going to name them because of confidentiality, but you 
definitely would know them.



Do you have any ideas for solving the problem at hand?


You probably know more about the options available in Jetty than I do.

The competition, a package with a feline name, has a native library that 
utilizes openssl for encryption duties.  I understand it's got far 
better performance than Java.  I couldn't locate anything other than the 
conscrypt solution, which you've said has problems.  I have no idea 
whether something like that exists for Jetty.  I couldn't locate 
anything other than the conscrypt solution, which you've said has problems.


Thanks,
Shawn
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] Fast SSL with jetty.

[Greg Wilkins]

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 localhost be acceptable?   Currently this
would use the not-really-ready-for-production JNR wrappers, but latest JVMs
do have unix socket support, so it is something we may soon add support for.










On Mon, 15 Mar 2021 at 01:55, Luke B  wrote:

> Hi Shawn,
>
> 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.
>
> Do you have any ideas for solving the problem at hand?
>
> cheers,
>
> Luke
>
> On Mon, Mar 15, 2021 at 11:42 AM Shawn Heisey 
> wrote:
>
>> On 3/14/2021 5:50 PM, Luke B wrote:
>> > Setting up jetty to listen only on localhost without SSL and having an
>> > nginx (or other web server) reverse proxy to provide SSL is possible
>> but
>> > unlikely something that is acceptable as encryption is required all the
>> > way to the java process. In this case a tcp dump would reveal passwords.
>>
>> Think about what would have to happen for somebody to get that packet
>> capture.
>>
>> 1) If the reverse proxy is on a different machine than Jetty, one way in
>> is for the attacker to have physical access to the hardware.  They could
>> patch a rogue machine in with two network ports and capture everything
>> going over the machine's wire.  A raspberry pi with a USB network dongle
>> could probably be used for that -- relatively easy to hide.
>>
>> 2) If the attacker manages to acquire remote access and admin/root
>> privileges, they could install tools on the machine (like tcpdump or
>> wireshark) to capture those packets whether the two processes are on the
>> same machine (using localhost) or on separate machines.
>>
>> If you have good physical security, the first attack is not going to
>> happen.
>>
>> If the second attack succeeds, you've got bigger problems than a lack of
>> encryption on the back end of your web services.  They've got admin/root
>> access, and might be able to obtain those privileges on other machines
>> through software vulnerabilities.  They would probably already have
>> access to everything they might glean from capturing unencrypted
>> packets.  An example: Credentials in config files for services like
>> mail, database, microservices, etc.
>>
>> It is my strong opinion that encrypting the connection between a
>> front-end reverse proxy or load balancer and back end web services is an
>> illusion of safety that comes at the expense of CPU time needed for the
>> extra encryption.
>>
>> Anybody is welcome to disagree with me.
>>
>> I worked at a company that was setting up services for a very high
>> profile customer.  That customer wanted the back end encrypted like you
>> do.  We did it, but I think it was unnecessary.
>>
>> Thanks,
>> Shawn
>> ___
>> 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
>


-- 
Greg Wilkins  CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users