felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff McAffer <Jeff_McAf...@ca.ibm.com>
Subject Re: http.jetty based on Jetty 6
Date Sat, 12 Jan 2008 18:09:28 GMT
Just for grins you might also want to look at the Equinox approach here. 
Jetty 6 support is on the way there too. 

Let a thousand flowers bloom...


"Richard S. Hall" <heavy@ungoverned.org> 
01/09/2008 10:07 AM
Please respond to


Re: http.jetty based on Jetty 6

Well, the original Felix project proposal was to implement the entire 
spec and bring open source OSGi communities together under one project. 
So, it seems to me that we should have our own and/or encouraging PAX to 
join us.

-> richard

Felix Meschberger wrote:
> Hi all,
> Thanks for the feedback and the pointers to Pax-Web at OPS4J. It quickly
> checked it out and it works for me.
> Now back to our Felix implementation: I just quickly hacked to gether
> some support upto the point, where it runs for me. I attached a patch to
> the Felix trunk to FELIX-55 and would be very happy if some others could
> throw an eye or two on it. Thanks alot.
> On the other, we might probably very well stick with what we have
> (either the original Jetty 4 based one) or an upgraded Jetty6 based one.
> I am kind of unsure as to where to go from now given that OPS4J pax-web
> has the latest and greatest Jetty 6 support ...
>    * Should we stay at Jetty 4 and release as-is (pre-Servlet 2.3
> compliant) ?
>    * Should we go for Jetty 6 and release (Servlet 2.5 compliant) ?
> WDYT ?
> Regards
> Felix
> Am Dienstag, den 08.01.2008, 17:46 +0100 schrieb Felix Meschberger:
>> Hi all,
>> As already noted I am working on integration Jetty 6 in the http.jetty
>> bundle. On the course, I wonder, whether it would make sense to include
>> the Servlet API required by Jetty 6 in this bundle.
>> My reasoning for this is, that the servlet API version is closely tied
>> to the Servlet Container implementation we are using to implement the
>> OSGi HTTP Service specification. By including the API we also manifest
>> this tie by exporting the API from the same bundle as the HTTP Service
>> implementation.
>> WDYT ?
>> Regards
>> Felix

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message