Hi Eoghan,
I found the log message "The SslSelectChannelConnector is a BETA
quality release."
when I played with the Jetty 6.1.1 SSLSelectChannelConnector in http2
moduel.
So I get the conclustion that Jetty6 SSL support is not stable.
I am not SSL experct, I can't tell exacly what specific features are
unstable or missing.
I just asked the Jetty guy for they help to know the status of the
Jetty 6 SSL support.
I hope I can get the answer soon.
Willem.
Glynn, Eoghan wrote:
Willem,
Can you give more detail on what your concerns were about the stability
or otherwise of Jetty 6 SSL support?
For example what specific features are considering buggy or entirely
missing?
Cheers,
Eoghan
-----Original Message-----
From: Glynn, Eoghan [mailto:[EMAIL PROTECTED]
Sent: 05 February 2007 15:17
To: [email protected]
Subject: RE: Duplication in http2 module
Well I think the original logic was that the Jetty6 SSL
support is in a pre-alpha state, so isn't suitable as a
straight replacement for Jetty5.
Hence the motivation for maintaining support for both Jetty5
and 6 for a transition period.
BTW I'm not sure if the Jetty6 SSL really is still that
unstable ... at least the mortbay.org download page, the 6.1
version has the status "Stable" and mentions "Async SSL" in the notes.
So before we waste any cycles on figuring out how to allow
Jetty 5 & 6 peacefully co-exist, I think it would be worth
investing some effort in establishing definitively the
stability or otherwise of Jetty6 SSL.
Now if Jetty6 is still considered unstable, then we'd have to
come up with some (e.g. class-loading) cleverness to allow
selective loading of the Jetty 5 or 6 artefacts. Fortunately
the Jetty 5 and 6 APIs expose different classes to our code
(e.g. SslListener versus SslSelectChannelConnector), so that
should simply things at compile time at least.
If on the other hand, we were happy enough to drop support
for Jetty5, this would simplify matters. For one thing, it
would allow the HTTP code to be restructured to take more
advantage of the non-blocking aspects of
Jetty6 (see my previous mail[1] for more detail).
However if we do drop Jetty5 support, before just replacing
the http module with http2, its important to do an audit to
ensure that all changes applied to the http module since the
advent of the duplicated
http2 module have also been reflected in the latter. Having
to do this sort of thing is another downside of the whole
duplication approach.
Cheers,
Eoghan
[1]
http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200
612.mbox/%
[EMAIL PROTECTED]
-----Original Message-----
From: Lin, Bozhong [mailto:[EMAIL PROTECTED]
Sent: 05 February 2007 14:37
To: [email protected]; [email protected]
Subject: RE: Duplication in http2 module
So I just want to follow up a question on this discussion. If we
agreed to refactor code according to the discussion, what this will
have impact on packaging? i.e., are we going to ship both
jetty5 and
jetty 6? or by default we just ship
jetty5 and let user download jetty6 if they want jetty6 support?
Regards,
Bo
-----Original Message-----
From: Glynn, Eoghan [mailto:[EMAIL PROTECTED]
Sent: Wed 1/31/2007 2:27 AM
To: [email protected]
Subject: RE: Duplication in http2 module
-----Original Message-----
From: Jiang, Ning [mailto:[EMAIL PROTECTED]
Sent: 31 January 2007 02:01
To: [email protected]
Subject: RE: Duplication in http2 module
Hi Eoghan,
Thank you for your reply.
You suggested to put the http2 into another branch which will not
effect the main line. It is easy to do in ClearCase. But
in svn, the branch is just a static copy from the mainline.
My question is if I put the http2 into a branch, when the
mainline
transport code had be changed, how can I sync these
mainline's changes
to the branch?
Well the synching up would be a manual process, as it is now with
http2 on the mainline but completely separate from the main http
module.
Now we are working on pull the common transport logic to
the abstract
Destination and Conduit. So there is another option, we
just move the
Jetty6 support code into the http module , then we can get ride of
http2 module.
Sure, that would be the preferred option, and basically I was
originally advocating such a merge into a single http
module (as long
as the duplication is also properly addressed).
The idea would be factor out the common logic into abstract base
classes, and then provide pluggable API-specific components for
Jetty5, Jetty6, and Servlet.
But IIRC you didn't want to do this refactoring as the Jetty6 stuff
was still pre-alpha and hence not suitable use in the main http
module. So the option to move to a branch was a second choice
alternative.
Cheers,
Eoghan
Cheers,
Willem.
-----Original Message-----
From: Glynn, Eoghan [mailto:[EMAIL PROTECTED]
Sent: Tue 1/30/2007 23:03
To: [email protected]
Subject: RE: Duplication in http2 module
-----Original Message-----
From: Willem Jiang [mailto:[EMAIL PROTECTED]
Sent: Tue 1/30/2007 4:00 AM
To: [email protected]
Subject: Duplication in http2 module
Hi Eoghan,
The original thought to add the module http2 was we can
replace the
Jetty5 with new NIO support Jetty6, than we can replace
http module
with http.
Unfortunately when I finished the porting , I found the
Jetty6 ssl
stuff
is still in a pre-alpha state. So I can move http2 to http.
There are some my random thoughts about the http2 module.
1. making the http transport decouple with the detail Http
Transport
engines.
In this way ,we can share the common http transport logical
code with
the different Http Transport engines.
So the CXF can support tomcat , Jetty5 , Jetty6 to provide the
standalone web services.
Yes, the whole point is that much of the logic in the
servlet, Jetty5-
and Jetty6-based HTTP transports is actually common to all
three and
hence is sharable via abstract base classes.
I'd already raised a JIRA issue
(http://issues.apache.org/jira/browse/CXF-343) to remove the
duplication from the servlet transport. A similar
unification approach
could also be used for the Jetty5 and Jetty6-based HTTP
transports.
2. If we want to support Jetty5 and Jetty6 in the same http
transport
module, how can we achieve it.
Simply by encapsulating all usage of Jetty-version-specific
APIs into
pluggable components.
In Jetty <=5, there was an API for pure Jetty HTTP requests and
responses. The Jetty requests and responses where wrapped by the
ServletHandler to provide the Servlet API for requests and
responses.
In Jetty 6, all requests and responses are based on the
Servlet APIs
requests and responses.
Sure the APIs are slightly different, but that doesn't
prevent sharing
all the code that actually is common.
Now the refactoring job is made easier by the fact that the logic
common to *all* Destination implementations (i.e. both HTTP and
non-HTTP) is now factored out into an AbstractDestination class.
However, there's still plenty of duplicated and potentially
sharable
logic in the three HTTP Destination implementations, e.g.
the logic
concerned with managing HTTP headers, acting on policies
and setting
message properties.
May be we need different Jetty factory to create the detail
JettyHTTPServerEngine and JettyHTTPDestionation which will
consume the
different version's Jetty API.
These will take some time to finish and we also need to
wait for the
Jetty6 SSL engine stable release. Eoghan, I agree we can put
the http2
into the branch which will not take effect with the mail line.
But I have no ideal how to sync the branch with the main
line's http
transport common logical. Can someone help me out ?
I don't understand what exactly you're asking for help with.
Can you elaborate?
Cheers,
Eoghan
Cheers,
Willem.
-----Original Message-----
From: Glynn, Eoghan [mailto:[EMAIL PROTECTED]
Sent: Mon 1/29/2007 18:13
To: [email protected]
Subject: Duplication in http2 module [was RE: svn commit:
r497869 -
/incubator/cxf/trunk/rt/transports/http2/src/main/java/org/ap
ache/cxf/t
ransport/http/JettyHTTPDestination.java]
Willem,
The problem with keeping these modules separate is that
every change to
the main http module has to be duplicated manually to the
http2 module
which is time-consuming and error-prone.
So if the http2 stuff is still in a pre-alpha state, then it
should be
taken off the mainline onto a branch until its ready to
either share
common base classes with the core (Jetty5-based) http
transport or
replace it outright.
Cheers,
Eoghan
-----Original Message-----
From: Willem Jiang [mailto:[EMAIL PROTECTED]
Sent: 19 January 2007 18:08
To: [email protected]
Subject: Re: svn commit: r497869 -
/incubator/cxf/trunk/rt/transports/http2/src/main/java/org/apa
che/cxf/transport/http/JettyHTTPDestination.java
Hi Eoghan,
The duplication in http transports is because I don't
want the
development of the Jetty6 support takes effect to the
current code
base.
Since Jetty6 's ssl support is in pre-alpha state , we
don't want to
replace Jetty5 with Jetty6 right now, I agree we can move
the Jetty6
supporting from rt-tranpsorts-http2 to rt-transports-http
to reduce
the duplication, and get CXF http-transport more flexible.
Cheers,
Willem.
Glynn, Eoghan wrote:
Hi Willem,
Why all the duplication in rt-transports-http2?
If we're going to keep the Jetty5-based rt-transports-http
stuff, then
the two modules should be merged so as to avoid
duplication, with
common code factored up into abstract base classes.
I've raised an JIRA task for a similar refactoring of the
duplication-heavy servlet code:
http://issues.apache.org/jira/browse/CXF-343
Cheers,
Eoghan
