| [jetty-dev] Re: http service configuration |
> Hi Simon,
>
> Not sure if your on the jetty-dev eclipse list or not yet so mailing
> both you and the list.
>
Thanks Jesse, I am now.
> Anyway, I have looked over the http service and have it updated to the
> 7.0.0.M0 artifacts of jetty7. Took a little detour and have a jetty7
> update site wired up now so I can get a feel for your eclipse oriented
> way to declaring and using dependencies....takes a bit of getting used
> too over maven. :)
>
> I took a bit of free time today and wanted to bring up the
> customization mechanism currently being used for this httpservice and
> hopefully you can educate me a bit on if this is the established osgi
> way of configuring things. It obviously works, but it seems awfully
> inflexible compared to the xml configuration mechanism that jetty
> currently has wired in.
>
> As I understand the current workings, it is _basically_ a fluffed up
> way of using a .properties type format for declaring specific
> configuration options to jetty and the httpservice. I don't see where
> we would be able to do anything like configure handlers or filters,
> much less declare multiple contexts and servlets in a single jetty
> instance given this osgi service.
>
You're right that this configuration mechanism is limited.
Currently what you're configuring is really just the server bit along with a
single context. We actually have patches to support multiple contexts
however I'm not intending on supporting this in the current release. So, for
now all requests to that single context are funneled through a Servlet
Handler which eventually routes into the HttpServiceServlet in
org.eclipse.equinox.http.servlet. When that servlet is "init"-ed it
registers a new instance of the OSGi Http Service and from that point
anything you might do in your web.xml is then done programatically through
the service's interface.
As Jeff pointed out the OSGi Http Service predates Servlet 2.2 and
subsequently is missing a number of features notably Filters and Listeners.
To date folk wanting to use Filters/Listeners have had to create specialized
Servlets to for example wrap a FilterChain. This works (and is used in
production systems) but is a bit of a pain. (There are some examples of
these wrapper classes in a project called "org.eclipse.equinox.http.helper"
located in the equinox incubator if you or anyone else is curious and wants
to take a look.)
> A quick way to support this sort of configuration would be to allow
> the httpservice to understand the xml format for configuration that
> jetty uses, which could easily do all of the server initialization,
> contexts, handlers, etc etc.
Yes, this is basically where I'm at too at least for the server bit.
Contexts and handlers we would likely have to think a bit more about to
ensure we end up with something that makes sense.
> But something tells me that might not be
> the most popular option if this is the preferred medium for osgi
> configuration.
Taking a quick glance at the code, what's being done by jetty.xml is easy
enough to map to other configuration mechanisms. With that said, I see no
reason why using a jetty.xml would not be the preferred format.
> There are some performance improvements we could also
> add in (using the SslSelectChannelConnector and other nio goop when
> appropriate).
Perhaps we should do this in 3.5. I recently updated the version in the core
IDE from 6.1.7 to 6.1.15 and this now looks to be available.
> There are a ton of features we could add to this thing
> to make it much more friendly to use. Stealing options from the maven
> plugin could be nice as well, monitoring directories for changes and
> reloading the bits that could be reloaded for hot deploy...lots of
> things. Handly all things I would want to put into a jetty plugin
> making use of these functionalities.
>
> The shortest path to an incredibly increasing functionality for this
> would be maybe put a key in the Dictionary being used that pointed to
> an Object that encapsulated the xml we normally use for jetty startup
> (jetty.xml)...a url resource, or something that gives us access to the
> xml and then we could just bootstrap up the server from there. Is
> this something that you think is reasonable for this service?
>
To avoid repeating myself ... Yes ;)
> thoughts and comments are welcome...maybe even just dumping out on the
> list the things that you hear bemoaned most commonly regarding the
> httpservice....and anyone is welcome to chime in on this.
>
I'll leave that for another day!
-Simon