Re: [jetty-dev] http service configuration

[Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>]

Great that you bring this up.
This is where I've been thinking we have the best opportunity for a clean break from the old OSGi Http Service and the inspiration for whatever comes next.
We're relying on you lot to get the dynamic configuration bits exactly right ;)

p.s. on the dev list now.

Greg Wilkins ---04/14/2009 07:46:09 PM---Note also that the servlet-3.0 specification has a lot

From:	Greg Wilkins <gregw@xxxxxxxxxxx>
To:	"Jetty @ Eclipse developer discussion list" <jetty-dev@xxxxxxxxxxx>
Cc:	simon.kaegi@xxxxxxxxx
Date:	04/14/2009 07:46 PM
Subject:	Re: [jetty-dev] http service configuration

---

Note also that the servlet-3.0 specification has a lot
of stuff about programmatic configuration of servlets and filters.

So anything programmatic should follow that closely where possible.

You can see the current 3.0 API (in flux) at
    https://svn.dev.java.net/svn/glassfish-svn/trunk/v3/web/javax.servlet

(you need a java.net account to see it)

cheers




Jeff McAffer wrote:
> Hey Jesse
> 
> Great that you are looking at this.  thanks.  I will just make a few 
> contextual points
> - the current behaviour is defined relative to the HTTP service spec 
> which is very old and predates a lot of the things that we commonly 
> talk/think about today.
> 
> - the current stuff is largely programmatic with some ability to tweak 
> things using config admin.  As you have seen, not the best
> 
> - There was some work done to allow the reading of web.xml.  I'm not 
> sure where that is or stands now.
> 
> - Sucking a Jetty XML file for configuration would be fine.  It would be 
> even better if that eventually made its way into a standard
> 
> - Even better would be something like your suggestion to have the core 
> take a configuration object of some sort and then that object can be 
> created/setup by either reading an XML file, programatically, ...
> 
> - when you get into the monitoring dirs for changes that is more in the 
> p2 camp.  In the context of an HTTP service there are no dirs to monitor 
> per se.  Everything is contributed using bundles that have dependencies 
> and classpath wirings and...  p2 has a lot of capabilities in this 
> area.  It would be very interesting to look at this integration to 
> ensure it works as expected/desired.
> 
> Jeff
> 
> Jesse McConnell wrote:
>> Hi Simon,
>>
>> Not sure if your on the jetty-dev eclipse list or not yet so mailing
>> both you and the list.
>>
>> 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.
>>
>> 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.  But something tells me that might not be
>> the most popular option if this is the preferred medium for osgi
>> configuration.  There are some performance improvements we could also
>> add in (using the SslSelectChannelConnector and other nio goop when
>> appropriate).  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?
>>
>> 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.
>>
>> cheers!
>> jesse
>>
>>
>> -- 
>> jesse mcconnell
>> jesse.mcconnell@xxxxxxxxx
>> _______________________________________________
>> jetty-dev mailing list
>> jetty-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/jetty-dev
>>   
> _______________________________________________
> jetty-dev mailing list
> jetty-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-dev

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