felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Poll - updating HTTP to newer jetty
Date Wed, 31 May 2006 22:35:55 GMT
Rob Walker skrev:
> 
>> Have you started to work on this? I'm interested in working on 
>> implementing a Jetty 6 HTTP service.
> Haven't started yet but am hoping to get a chance to look in next week 
> or two.

I might be able to look at it sooner, in that case I post my findings 
immediately so that we avoid any double work.

>> As some background we are working on making Cocoon OSGi based. This 
>> far we use the Equinox framework and bundles as we rely heavily on 
>> declarative services, which hasn't been part of Felix until recently. 
>> The HTTPservice in Equinox that we have used until now take a 
>> fundamentalistic view on spec compliance and use servlet 2.1, while 
>> this have worked well during prototyping it is more or less unusable 
>> in a modern web framework. I have tried to switch to the current Felix 
>> HTTP service to be able to use servlet 2.3 but have got all kinds of 
>> classloading problems (unfortunately I'm not able to give any concise 
>> bug report as I don't have any clue about what happens). I have also 
>> tried the Oscar and Knopflerfish services who both works in my 
>> setting, but doesn't implement e.g. contextpath in a meaningful way.
> I think the problem here is going to be that to be a properly OSGi  
> usable bundle, will probably mean several things:
> 
> 1 - the base HTTP service we will make stick as close to OSGi compliance 
> as possible, which as you've found is a fairly "minimalist" Http service 
> in terms of more general web application facilities

I agree with that it should stick as close to OSGi compliance as 
possible. The only difference that I'd like at the moment is using 
Servlet 2.5 instead of Servlet 2.1 (actually I would be completely happy 
already with 2.3).

> 2 - I've heard that extensions and enhancements are in the wings to 
> improve what a standard OSGi HttpService offers - we'd look to implement 
> these as soon as available, but until then any richer "web frameworks" 
> will need to be by custom services and APIs. I believe a few others have 
> looked at providing extensions to offer richer, more standard web-app 
> capabilities on top of an OSGi service and was planning to send out a 
> poll once the Jetty6 work is done for who had what, and what interest 
> there was in standardizing an extended set of services

There is some work within OSGi on some kind of webapp service(s), 
unfortunately they insist on continuing old fashioned closed 
specification development so I have no idea what they are up to.

> I need to look back over the servlet JAR level discussion thread - 
> suffice to say, we'll try and balance spec compliance with the interest 
> for support as recent a level of servlet spec as possible.
>> Jetty 6 seem to be designed for embedding and doesn't seem to require 
>> context classloader tricks.
>>
> True in terms of embedding, it does which I'm very glad to see and shall 
> be even happier if it turns out simpler than the current model we use.
> 
> Classloading wise though, any integration will have to fit the standard 
> OSGi classloading model, which hopefully won't require classloader 
> tricks per se but still presents the potential for somewhat tricky 
> classloading errors at least during initial application implementation. 
> More recent versions of Felix have got a whole lot easier in terms of 
> meaningful messages to help trace these though.

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.

/Daniel

Mime
View raw message