Rob Walker skrev:
I might be able to look at it sooner, in that case I post my findings
immediately so that we avoid any double work.
Cool - I was expecting to look at it in next few days, but have no
problem if you want to pitch in first.
I'm working on the implementation now. The architecture and the APIs of
Jetty6 has changed considerably since Jetty4 so it took some time to
figure out how to modify the current http.jetty implementation so that
it works with Jetty6. I'll put the code in Jira as soon as I have
something working.
My plan was to SVN copy the current http.jetty to a new http.jetty6
bundle initially, so that others use it and give feedback whilst keeping
the previous version intact for those wishing to stay on the stable
Jetty4 version. Also, this will track the mod deltas back to the
original too - so we won't lose any change information.
Have followed that.
I'm also hoping to significantly clean-up the rather tricky way that we
need to wire into the standard Jetty stack,
That seem to be possible, Jetty6 seem to be a little bit more open for
extension than Jetty4.
and improve the way Jetty
logging is integrated with Felix logging.
I will probably wait with that.
I have no problem with the OSGi classloading model, quite the
opposite. What I refered to is that it seem like at least the Oscar
http service require that one resets the context classloader in some
use cases where this isn't necessary for the Equinox http service.
This complicates the use of it.
From what I recall, the Oscar http service doesn't require use of
context classloader itself - there are numerous cases of third party
JARs which do e.g. various XML / SAX parsers etc. I'm guessing if you
found a need for your application to set a context classloader it was as
a result of a 3rd party JAR which was required by one your services
rather than the HTTP service itself.
Might be, I'm not certain. I needed to change the context class loader
while using the Oscar http service but not while using the Equinox one.
/Daniel
