Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Jetty 9 + Websocket Modules

Joakim,

I don't really like the idea of perverting our software design too
much for webapp classloading issues.
Ie if Callback is more natural and efficient than Future, the we
should use it.     The only reason I can see for switching to Futures,
is if it makes implementing JSR-356 significantly easier.

I understand there is an issue of exposing Callback to a webapp
classloader, but I expect that in the near future our Websocket API
will be viewed primarily as the way that we implement our JSR-356
implementation.
Ie. in the short term, I'm happy to live with the need to adjust the
system classpaths to expose our websocket API/Implementation where
needed.

Having said that - I think it is a very good exercise to go through
the websocket packaging and to be very explicit like you have been
about what modules a webapp will need to depend on and which of those
need to be in WEB-INF/lib vs being provided.

I think the end game would have to be that for simple websocket apps,
there needs to be no jars in WEB-INF/lib and  the JSR-356 API is
provided and able to be used.   If webapps want to use jetty specific
APIs then they need to adjust the system path (and I'm open to better
ways of doing that than jetty-web.xml).   If they want to use the
client then they need to provide jars.

So having set those parameters to my thinking - I think your module
breakdown looks fine.  Can you get it done  before M2?

cheers


Back to the top