Community
Participate
Working Groups
In an internal application we have been reusing Orbit's packaging of httpclient. Thanks a lot for providing it here. When we upgraded to 4.1 we found out that the method org.apache.http.conn.ssl.SSLSocketFactory#createSocket does not create SSLSocket anymore. I apologize for giving the details of the issue here: I could not find any bugs on apache reporting the issue and its fix (you can look here: https://issues.apache.org/jira/browse/HTTPCLIENT/fixforversion/12316282). Here is the source in 4.1: /** * @param params Optional parameters. Parameters passed to this method will have no effect. * This method will create a unconnected instance of {@link Socket} class. * @since 4.1 */ public Socket createSocket(final HttpParams params) throws IOException { return new Socket(); } @Deprecated public Socket createSocket() throws IOException { return new Socket(); } In 4.1.1: public Socket createSocket(final HttpParams params) throws IOException { return this.socketfactory.createSocket(); } @Deprecated public Socket createSocket() throws IOException { return this.socketfactory.createSocket(); } And in 4.0 // non-javadoc, see interface org.apache.http.conn.SocketFactory @SuppressWarnings("cast") public Socket createSocket() throws IOException { // the cast makes sure that the factory is working as expected return (SSLSocket) this.socketfactory.createSocket(); } I have a workaround for my internal application so I can still use 4.0. I hope this useful; I am not sure when an upgrade to 4.1.1 is possible; let me know if I can help.
IMHO we should upgrade ASAP. Is there a CQ already?
There is no CQ for it; I don't mind filing one although none of the applications I contribute to at eclipse use it. The impact might be more limited that it looks: not many applications use directly the SSLSocketFactory: it is not a dropin replacement for java.net.SSLSocketFactory. Most applications I know use the HttpClient api which does not rely on this SSLSocketFactory.
Can you create a CQ? Things are getting a bit tight for Indigo. We should notify the IP team that this is a critical issue for some projects that the update be included as part of Indigo.
I don't mean to be a stick in the mud (well, I sort of do :), but I don't think we should say it is "needed for indigo" unless we know of a specific Eclipse project that needs it. From reading the existing CQ connections, it appears Mylyn consumes this, so maybe they would want to update, once they've heard about the bug? ... so, I've added Steffen to CC list. Naturally, if I've misunderstood, feel free to correct me, and any Eclipse Project that needs it can open the CQ.
Hugues, does jetty needs this for Indigo?
For Mylyn we are using a custom socket factory implementation so I don't think this bug affects us. Would be nice to have the fix for Indigo but it's not critical for us.
Chris, David, not a problem for jetty. Jetty does not depend on this library. For Intalio's internal project we extend that org.apache.http.conn.ssl.SSLSocketFactory override the createSocket methods and we are fine.
Ok, so I think we've established so far not _required_ for indigo ... but, someone should still enter a CQ, and get this in the pipeline. (The fact that it's a service release should make it easier to get through the process ... but, still, would receive less priority if not _required_ for Indigo). Any takers? Thanks
Assigning to Chris as the contact of current versions (e.g. 4.1.0) ... though if/when someone wants 4.1.1 the contact could change.
Considering the number of bug fixes in the service releases of HttpCore and HttpClient I wonder if there is interest in updating the Orbit bundles to the latest upstream release? http://www.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.1.x.txt http://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES-4.1.x.txt
(In reply to comment #10) > Considering the number of bug fixes in the service releases of HttpCore and > HttpClient I wonder if there is interest in updating the Orbit bundles to the > latest upstream release? > > http://www.apache.org/dist/httpcomponents/httpclient/RELEASE_NOTES-4.1.x.txt > http://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES-4.1.x.txt I think it'd be great ... but, we still need an Eclipse Project to first say they need it (by filing a CQ) and once that's approved, do an Orbit CQ for it, then add it. Should be simpler for IP staff than usual, since minor release (4.1.0 to 4.1.1 ... oh, they are up to 4.1.4 now), but, still need the usual process. But, I think it'd be great to get current. It makes things especially easier for other distributors (e.g. Fedora) that depend on "shipping the latest" in their stacks. And, Steffan, I'm not sure if Chris has a vested in interest in this bundle, but sounds like you do? If so, you might be able to talk Chris in becoming the new "owner" ... if you are willing :) [And, I'm not saying that's required ... just a thought.]
Mylyn (finally) started using an HTTP components based transport layer and we'll ship the bundles as part of the Mylyn Hudson connector for Juno. So, we have indeed an interest in the bundles :). I'll initiate CQs for the latest release versions and figure out ownership for the Orbit bundles with Chris once the CQs are approved.
I have filed the following CQs for Mylyn Commons: 5925: Apache HttpComponents Core Version: 4.1.4 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5925 5926: Apache HttpComponents Client Version: 4.1.2 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5926 5927: Apache HttpComponents Client Mime Version: 4.1.2 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5927
I just noticed https://issues.apache.org/jira/browse/HTTPCORE-257 which prevents reuse of connections when a gzipped response is returned which is a fairly major problem for Mylyn as it will have an impact on performance and resource consumption.
(In reply to comment #14) > I just noticed https://issues.apache.org/jira/browse/HTTPCORE-257 which > prevents reuse of connections when a gzipped response is returned which is a > fairly major problem for Mylyn as it will have an impact on performance and > resource consumption. Which is fixed in the 4.1.4 you are proposing to include for Juno, right? If the bug is also in 4.1.0 (which we have in Indigo) I wonder if it would effect p2? (when getting pack.gz files?) If so ... might be worth considering to put into Indigo SR2 ... but ... not much time left for that so might not be feasible. (even if in 4.1.0, and even if effects p2 ... both of which "just guesses" on my part ... no idea if or how to tell). But, thanks for documenting.
(In reply to comment #15) > (In reply to comment #14) > > I just noticed https://issues.apache.org/jira/browse/HTTPCORE-257 which > > prevents reuse of connections when a gzipped response is returned which is a > > fairly major problem for Mylyn as it will have an impact on performance and > > resource consumption. > > Which is fixed in the 4.1.4 you are proposing to include for Juno, right? Yes, I would like to have that bundle for Juno (possibly earlier so we can consume it for the next Mylyn release scheduled for end of February). > If the bug is also in 4.1.0 (which we have in Indigo) I wonder if it would > effect p2? (when getting pack.gz files?) I thought p2/ECF was still using an HttpClient 3.1 based transport in Indigo which does not have this bug. My understanding is that gzip encoding is only used for files that aren't already compressed. Since p2 uses jars and gz files in most cases this bug would only cause connection reuse to fail when transferring xml or index files which would only have a limited impact on performance.
(In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > I just noticed https://issues.apache.org/jira/browse/HTTPCORE-257 which > > > prevents reuse of connections when a gzipped response is returned which is a > > > fairly major problem for Mylyn as it will have an impact on performance and > > > resource consumption. > > > > Which is fixed in the 4.1.4 you are proposing to include for Juno, right? > > Yes, I would like to have that bundle for Juno (possibly earlier so we can > consume it for the next Mylyn release scheduled for end of February). > > > If the bug is also in 4.1.0 (which we have in Indigo) I wonder if it would > > effect p2? (when getting pack.gz files?) > > I thought p2/ECF was still using an HttpClient 3.1 based transport in Indigo > which does not have this bug. That's correct...ECF is still using HttpClient 3.1-based transport in Indigo.
> > Yes, I would like to have that bundle for Juno (possibly earlier so we can > consume it for the next Mylyn release scheduled for end of February). > Perhaps a side issue, but, to be explicit, is your Mylyn release "end of February" part of Indigo SR2? If so ... you know the schedule. :) If not, how do you get a "released" version of the Orbit bundle into your released version of Mylyn? Ideally, you'd have an "R build" so you'd know it'd persist ... and if not part of Indigo, that'd mean you could be asking for another R build very shortly after the R build for Indigo SR2. Technically ok, if you need it ... just figured I should say a) you'll have to ask explicitly if you need it, and b) it would be easier to get into the Indigo R build if that is possible (and safe). Or ... you could use a version of an I-build and hope if doesn't change for Juno ... but, if it does, your I-build version might "disappear" ... and maybe that's fine for your case ... just thought I'd clarify, if it wasn't already.
(In reply to comment #18) > Perhaps a side issue, but, to be explicit, is your Mylyn release "end of > February" part of Indigo SR2? If so ... you know the schedule. :) It's going to be around the same time frame but we will not contribute it to Indigo. > If not, how do > you get a "released" version of the Orbit bundle into your released version of > Mylyn? Good question. In the past we released bundles that were part of Orbit S-builds. It can make it difficult to reproduce the exact same build after the S-build has been removed but in practice Orbit bundles tend to be very stable meaning we have always been able to upgrade the build to an R-build later, e.g. when doing service releases from an S-build based stream. > Ideally, you'd have an "R build" so you'd know it'd persist ... and if > not part of Indigo, that'd mean you could be asking for another R build very > shortly after the R build for Indigo SR2. Technically ok, if you need it ... > just figured I should say a) you'll have to ask explicitly if you need it, and > b) it would be easier to get into the Indigo R build if that is possible (and > safe). Thanks for pointing that out. From my perspective it would be sufficient to have an S-build. We generally only support the release train releases "long term" (usually for a year) and we have less strict requirements for the intermediate releases.
The first CQ for HttpCore has been approved. Chris, do you have cycles to update the Orbit bundle? If not, feel free to assign the bug to me.
The remaining two CQs have been approved as well. We are good to update the Orbit bundles to the latest versions. Chris?
I would like to proceed with putting the updated HttpComponent libraries into Orbit. Chris, I'll grab this bug for now. Please feel free to take it back if you intend to work on this.
The ATO CQs were approved as well. I have committed updated versions of the bundles which will be included in the next Orbit I-build.
