You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Rob Walker <ro...@ascert.com> on 2006/05/24 10:51:55 UTC
Poll - updating HTTP to newer jetty
I'm interested in views on updating our http to a newer Jetty version
- a 5.x release will probably be a fairly painless move, since the
architecture hasn't changed much
- a 6.x will probably take more effort, but also mean we catch the "next
wave" of Jetty optimisations early
Anyone got any views/preferences - not sure I'll get time to do both,
and although it's riskier since 6.0 is still in alpha it also seems to
have more long term mileage in it. Anyone wanting a "stable" http can
still use the current 4.x if they're not ready for the change.
Thoughts?
-- Rob
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Poll - updating HTTP to newer jetty
Posted by Upayavira <uv...@odoko.co.uk>.
Rob Walker wrote:
> I'm interested in views on updating our http to a newer Jetty version
>
> - a 5.x release will probably be a fairly painless move, since the
> architecture hasn't changed much
> - a 6.x will probably take more effort, but also mean we catch the "next
> wave" of Jetty optimisations early
>
> Anyone got any views/preferences - not sure I'll get time to do both,
> and although it's riskier since 6.0 is still in alpha it also seems to
> have more long term mileage in it. Anyone wanting a "stable" http can
> still use the current 4.x if they're not ready for the change.
AFAIU, 5.x uses commons logging, which has caused problems with at least
two applications I've tried to upgrade from 4->5. 6 has removed it, and
worked fine. Personally, I'd go with 6.0.
Upayavira
Re: Poll - updating HTTP to newer jetty
Posted by "Richard S. Hall" <he...@ungoverned.org>.
If your time if only going to give you one shot, then I say go straight
to 6.0 since this effort will give us the most long-term bang for the buck!
-> richard
Rob Walker wrote:
> I'm interested in views on updating our http to a newer Jetty version
>
> - a 5.x release will probably be a fairly painless move, since the
> architecture hasn't changed much
> - a 6.x will probably take more effort, but also mean we catch the
> "next wave" of Jetty optimisations early
>
> Anyone got any views/preferences - not sure I'll get time to do both,
> and although it's riskier since 6.0 is still in alpha it also seems to
> have more long term mileage in it. Anyone wanting a "stable" http can
> still use the current 4.x if they're not ready for the change.
>
> Thoughts?
>
> -- Rob
>
>
> Ascert - Taking systems to the Edge
> robw@ascert.com
> +44 (0)20 7488 3470
> www.ascert.com
>
>
Re: Poll - updating HTTP to newer jetty
Posted by Timothy Bennett <ti...@gmail.com>.
On 5/31/06, Daniel Fagerstrom <da...@nada.kth.se> wrote:
>
> Jetty 6 seem to be designed for embedding and doesn't seem to require
> context classloader tricks.
Does Jetty 6 required JDK 1.5?
--
timothy
Re: Poll - updating HTTP to newer jetty
Posted by Rob Walker <ro...@ascert.com>.
Daniel Fagerstrom wrote:
> 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.
Good news and thanks! You've taken one off my list, which just leaves me
mangen to worry about. More than happy to assist and or review code or
design ideas/approaches if you want help or input on the approach.
There's a bugfix workaround submitted in JIRA to do with \* aliases for
Http that I was going to apply to current Jetty4 version and see if was
relevant for Jetty6. Don't worry if you don't have time for that as well
- I can come back and look at it when I look at the new Jetty6 based
Http code.
> 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.
Context classloader issues are a bit of a pain in OSGi - in most cases
it's a 3rd party JAR that needs it setting to do dynamic classloading
(usually SAX parsers are the most prevalent case).
-- Rob
Re: Poll - updating HTTP to newer jetty
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: Poll - updating HTTP to newer jetty
Posted by Rob Walker <ro...@ascert.com>.
> 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.
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.
I'm also hoping to significantly clean-up the rather tricky way that we
need to wire into the standard Jetty stack, and improve the way Jetty
logging is integrated with Felix logging.
> 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.
Regards
-- Rob
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Poll - updating HTTP to newer jetty
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: Poll - updating HTTP to newer jetty
Posted by Rob Walker <ro...@ascert.com>.
> 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.
> 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
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
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.
Regards
-- Rob
Re: Poll - updating HTTP to newer jetty
Posted by Rob Walker <ro...@ascert.com>.
Interesting one.
Have to say, I hadn't envisaged this as a general or frequent case i.e.
we're creating a Jetty6 variant as a short term parallel case so brave
people can try the new version but also those who need stability keep
access to the old version.
It's also simple in that HTTP only has one principle JAR it depends on -
Jetty - so we only need 1 version number. Actually, I guess it could get
messy if multiple servlet JAR versions were possible - but I think for
now, http.jetty will imply a given servlet version, and http.jetty6 will
imply a (probably higher) servlet JAR version.
For short term pragmatism - I can live with http.jetty and http.jetty6 -
but if we want to come up with a more symmetric and re-usable naming
then maybe
http.jetty-v4-n
with of various possible alternatives:
http.jetty.v4.n
http.jetty_v4_n
and then of course the v6 one would just be an extension of this.
And darned - now I read your email back - I realise you were talking
about bundle symbolic names, not necessarily file or directory names ...
although I think this would effectively follow the same course ... this
is "http.jetty version M.n"
-- Rob
Jeff McAffer wrote:
> As a point of interest, what are the bundle symbolic names for these two
> Jetty bundles? I ask because we've been struggling with how to name
> bundles that contain new versions of something like Jetty. That is,
> should the bundles be
> http.jetty version 4
> http.jetty version 6
> or
> http.jetty version ???
> http.jetty6 version ???
>
> Similarly for things like a servlet API bundle.
>
> We are pretty open. It would be interesting to see if we can align on
> this naming.
>
> Jeff
>
>
>
>
>
> Rob Walker <ro...@ascert.com>
> 06/06/2006 07:59 AM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Re: Poll - updating HTTP to newer jetty
>
>
>
>
>
>
> Agreed.
>
> I think we have that covered:
>
> http.jetty - will remain as is for now
> http.jetty6 - will be an SVN copy from http.jetty for versioning
> purposes, over which the Jetty6 mods will be made
>
> At some later stage we can decide if it makes sense to merge back down
> to jetty service based on Jetty6.
>
> -- Rob
>
> Richard S. Hall wrote:
>
>> Should we be maintaining our current HTTP Service implementation with
>> Jetty4 compiled for JDK1.2 for those people in environments where
>> upgrading is not possible?
>>
>> -> richard
>>
>> Rob Walker wrote:
>>
>>>> Does Jetty 6 required JDK 1.5?
>>>>
>>>>
>>> Sorry for delay in replying - you got stuck in my spam filter.
>>>
>>> No, I don't think so, I think it needs 1.4+, which should be fine.
>>> I'm planning on making this jetty6 (or renaming old to jetty4) so we
>>> don't lose current line anyhow.
>>>
>>> Regards
>>>
>>> -- Rob
>>>
>>>
>>> Ascert - Taking systems to the Edge
>>> robw@ascert.com
>>> +44 (0)20 7488 3470
>>> www.ascert.com
>>>
>>>
>>>
>
>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Poll - updating HTTP to newer jetty
Posted by Jeff McAffer <Je...@ca.ibm.com>.
As a point of interest, what are the bundle symbolic names for these two
Jetty bundles? I ask because we've been struggling with how to name
bundles that contain new versions of something like Jetty. That is,
should the bundles be
http.jetty version 4
http.jetty version 6
or
http.jetty version ???
http.jetty6 version ???
Similarly for things like a servlet API bundle.
We are pretty open. It would be interesting to see if we can align on
this naming.
Jeff
Rob Walker <ro...@ascert.com>
06/06/2006 07:59 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: Poll - updating HTTP to newer jetty
Agreed.
I think we have that covered:
http.jetty - will remain as is for now
http.jetty6 - will be an SVN copy from http.jetty for versioning
purposes, over which the Jetty6 mods will be made
At some later stage we can decide if it makes sense to merge back down
to jetty service based on Jetty6.
-- Rob
Richard S. Hall wrote:
> Should we be maintaining our current HTTP Service implementation with
> Jetty4 compiled for JDK1.2 for those people in environments where
> upgrading is not possible?
>
> -> richard
>
> Rob Walker wrote:
>>
>>>
>>> Does Jetty 6 required JDK 1.5?
>>>
>> Sorry for delay in replying - you got stuck in my spam filter.
>>
>> No, I don't think so, I think it needs 1.4+, which should be fine.
>> I'm planning on making this jetty6 (or renaming old to jetty4) so we
>> don't lose current line anyhow.
>>
>> Regards
>>
>> -- Rob
>>
>>
>> Ascert - Taking systems to the Edge
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>>
>>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Poll - updating HTTP to newer jetty
Posted by Rob Walker <ro...@ascert.com>.
Agreed.
I think we have that covered:
http.jetty - will remain as is for now
http.jetty6 - will be an SVN copy from http.jetty for versioning
purposes, over which the Jetty6 mods will be made
At some later stage we can decide if it makes sense to merge back down
to jetty service based on Jetty6.
-- Rob
Richard S. Hall wrote:
> Should we be maintaining our current HTTP Service implementation with
> Jetty4 compiled for JDK1.2 for those people in environments where
> upgrading is not possible?
>
> -> richard
>
> Rob Walker wrote:
>>
>>>
>>> Does Jetty 6 required JDK 1.5?
>>>
>> Sorry for delay in replying - you got stuck in my spam filter.
>>
>> No, I don't think so, I think it needs 1.4+, which should be fine.
>> I'm planning on making this jetty6 (or renaming old to jetty4) so we
>> don't lose current line anyhow.
>>
>> Regards
>>
>> -- Rob
>>
>>
>> Ascert - Taking systems to the Edge
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>>
>>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Poll - updating HTTP to newer jetty
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Should we be maintaining our current HTTP Service implementation with
Jetty4 compiled for JDK1.2 for those people in environments where
upgrading is not possible?
-> richard
Rob Walker wrote:
>
>>
>> Does Jetty 6 required JDK 1.5?
>>
> Sorry for delay in replying - you got stuck in my spam filter.
>
> No, I don't think so, I think it needs 1.4+, which should be fine. I'm
> planning on making this jetty6 (or renaming old to jetty4) so we don't
> lose current line anyhow.
>
> Regards
>
> -- Rob
>
>
> Ascert - Taking systems to the Edge
> robw@ascert.com
> +44 (0)20 7488 3470
> www.ascert.com
>
>
Re: Poll - updating HTTP to newer jetty
Posted by Rob Walker <ro...@ascert.com>.
>
> Does Jetty 6 required JDK 1.5?
>
Sorry for delay in replying - you got stuck in my spam filter.
No, I don't think so, I think it needs 1.4+, which should be fine. I'm
planning on making this jetty6 (or renaming old to jetty4) so we don't
lose current line anyhow.
Regards
-- Rob
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Poll - updating HTTP to newer jetty
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Have you started to work on this? I'm interested in working on
implementing a Jetty 6 HTTP service.
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.
Jetty 6 seem to be designed for embedding and doesn't seem to require
context classloader tricks.
/Daniel
Rob Walker skrev:
> I'm interested in views on updating our http to a newer Jetty version
>
> - a 5.x release will probably be a fairly painless move, since the
> architecture hasn't changed much
> - a 6.x will probably take more effort, but also mean we catch the
> "next wave" of Jetty optimisations early
>
> Anyone got any views/preferences - not sure I'll get time to do both,
> and although it's riskier since 6.0 is still in alpha it also seems to
> have more long term mileage in it. Anyone wanting a "stable" http can
> still use the current 4.x if they're not ready for the change.
>
> Thoughts?
>
> -- Rob
>
>
> Ascert - Taking systems to the Edge
> robw@ascert.com
> +44 (0)20 7488 3470
> www.ascert.com
>