Re: [jetty-dev] Jetty 9 + Websocket Modules

[Joakim Erdfelt <joakim@xxxxxxxxxxx>]

I see the question more about what do we expose in the API for developers to use?

Future seems a reasonable enough level to expose at the API level.

Internally, our impl would still use the Callback class, as that's how we have the new I/O layers created.

I see no real need to expose that level to the developers that want to use websocket.

Only async websocket write uses the Callback classes at the moment.

Ideally, I'd like to fix the namespaces to be more isolated in terms of what they 'let through' in the system classes.

I agree that we shouldn't depend on people putting provided classes/jars in the WEB-INF/lib.

The exercise on how to isolate classes and limit the exposure through the classloader was a thought experiment on what would be used by developers in a dependency sense (mentioning what would go in WEB-INF/lib was merely a way to frame the discussion on what to expose)

--

Joakim Erdfelt <joakim@xxxxxxxxxxx>

webtide.com

Developer advice, services and support
from the Jetty & CometD experts

eclipse.org/jetty - cometd.org

On Thu, Nov 1, 2012 at 2:31 PM, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

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

_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jetty-dev