Bugzilla – Full Text Bug Listing
| Summary: | add httpcomponents client 4.3.6 for ECF, p2, and Orbit | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David Williams <david_williams> | ||||||
| Component: | Releng | Assignee: | David Williams <david_williams> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | slewis, tjwatson | ||||||
| Version: | 4.5 | ||||||||
| Target Milestone: | 4.5 M4 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 453675 | ||||||||
| Attachments: |
|
||||||||
|
Description
David Williams
Seems the other bug fixed in 4.3.5, also related to proxies was https://issues.apache.org/jira/browse/HTTPCLIENT-1531 "https connections through proxies don't work if authentication is disabled" CQ submitted: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8833 In bug 422665, a user pointed out that the Apache project actually provides and OSGi bundle, as well as the more classical "Java Jar". Not sure when they started this, but either, "just now", or maybe with previous 4.3.4 version and I just didn't notice. I did notice, last release and this 4.3.5 version, that the "osgi" package is in an "examples" folder in the "source" package ... and I recall thinking before that must mean it's experimental, or highly customized. I've compared the two, and taken a close look at the OSGi bundle. I don't think we can use the bundle "as is", as it actually packages all of it's pre-reqs as "internal packages" (i.e. not exported or visible to others) which doesn't seem like the way we normally do componentization) ... the "prereqs" being commons-logging, codec. and httpcomponents-core itself. BUT, it may make a difference with our "proxy" problems, because it has a "bundle activator" called org/apache/http/osgi/impl/HttpProxyConfigurationActivator. I don't now enough about the subject matter to know if this is important, or, perhaps, if this is part of the bundle providing and OSGi Service? I'll attach the MANIFEST.MF bundle here, and attach a zip of the "osgi package". Created attachment 248072 [details]
MANIFEST.MF from Apache project's "OSGi version"
Notice the "activator" ... and that it comes from the OSGI package.
Also notice there's some "build specific" items in there ... at least, I'm assuming that's what they are ...
Embed-Dependency: *;scope=compile|runtime;inline=true
Include-Resource: (obviously build-time related, since has developers name "oleg" as part of the directory structure.
Private-Package: (assuming this is an "build-time" way to specify "don't export these". But, the bundle itself does contain them ... and would hate to think that's the "right" way to package up bundles?
Created attachment 248073 [details]
zip of "osgi package"
Perhaps some of you can make better sense of what these bundles are doing, especially the "activator" and/or anything related to "services"?
I'll update CQ to include the 'source' for the OSGI package ... just in case we do want to go that route, and assume we could "experiment" to have 4.3.5 with or without the "OSGi stuff" from the Apache project ... but, obviously, since we can't even reproduce the problem, due to lack of "proxy servers" it would be hard for us to verify if one worked and the other didn't.
Tom, CCing you in case you have any quick insights into the MANIFEST.MF or "osgi package". My main concern is since "this is new" that it *might* mean that some code was re-written and will only work work correctly (if in an OSGi environment) if this Activator is included ... and I am not sure if any thing else is implied, or not (such as, are clients supposed to use "getService" to get an connection, or something). (In reply to David Williams from comment #6) > Tom, CCing you in case you have any quick insights into the MANIFEST.MF or > "osgi package". > > My main concern is since "this is new" that it *might* mean that some code > was re-written and will only work work correctly (if in an OSGi environment) > if this Activator is included ... and I am not sure if any thing else is > implied, or not (such as, are clients supposed to use "getService" to get an > connection, or something). There are two services that get registered. 1) org.apache.http.osgi.services.HttpClientBuilderFactory - this seems like an OSGi way of calling the static method org.apache.http.impl.client.HttpClientBuilder.create() which then can be augmented by configured org.apache.http.osgi.services.ProxyConfiguration 2) There is a ManagedServiceFactory that managed registered org.apache.http.osgi.services.ProxyConfiguration objects. These are configured using configuration admin. In order to be useful we would have to include the Equinox implementation of ConfigurationAdmin so that clients can configure the ProxyConfiguration object. But this will require a significant shift in how everything in eclipse uses the httpclient. May not be a bad thing, but not sure who is willing to do the work or investigation on using this stuff. I would imagine all the static "java only" APIs should still work in an OSGi environment. (In reply to Thomas Watson from comment #7) > (In reply to David Williams from comment #6) <stuff deleted> > > There are two services that get registered. > > 1) org.apache.http.osgi.services.HttpClientBuilderFactory - this seems like > an OSGi way of calling the static method > org.apache.http.impl.client.HttpClientBuilder.create() which then can be > augmented by configured org.apache.http.osgi.services.ProxyConfiguration It seems possible to me that this could do some necessary configuration of NTLMv2 proxy auth support that is not being done by our Orbit version, although I still don't think it's too likely. > > 2) There is a ManagedServiceFactory that managed registered > org.apache.http.osgi.services.ProxyConfiguration objects. These are > configured using configuration admin. > > In order to be useful we would have to include the Equinox implementation of > ConfigurationAdmin so that clients can configure the ProxyConfiguration > object. But this will require a significant shift in how everything in > eclipse uses the httpclient. May not be a bad thing, but not sure who is > willing to do the work or investigation on using this stuff. True that. ECF filetransfer would be relatively easy I believe, and we don't have resources to commit to it. There are several other projects (e.g. Mylyn and probably many others that I don't know about) that depend directly upon the Orbit httpclient/httpcomponents bundles. Speaking of "moving targets" ... as of NOW, I see there has also been an update to the httpcore bundle of httpcomponents, moving up to "4.3.3" (instead of previous 4.3.2): https://hc.apache.org/downloads.cgi I'm ?guessing? none of these fixes effect "us" much? But, seems if we want to "stay current" we should probably update the "core" also. And, you'll recall I mentioned their "httpclient OSGi bundle" included everything ... hence, good example of why its important to do proper componentization. I do not know if their "super client bundle" included these fixes (they are not mentioned in release notes) ... perhaps "the client" bundle doesn't need them? ... or, perhaps they will be coming out with a 4.3.6 version of OSGi client soon to include them in their "super bundle"!? I think I will not try to update these for M3, after all, and instead wait to see what happens next. Might have to join their mailing list! And, perhaps a reason not to try and use (and "hack up") their "OSGi bundle"? = = = = = = Release 4.3.3 ------------------- This maintenance release fixes several bugs found since 4.3.2, mostly in the NIO transport components. All users of HttpCore 4.3 are advised to upgrade. Changelog ------------------- * Make a connection exception throw a ConnectException instead of a SocketTimeoutException to allow a FutureCallback handler to correctly distinguish between the two events. Contributed by Asankha Perera <asankha@apache.org> * [HTTPASYNC-77] system resources are not correctly deallocated if I/O reactor is shut down while still inactive (not started) Contributed by Oleg Kalnichevski <olegk at apache.org> * [HTTPCORE-379] shut down non-blocking server side connection in case of an i/o or runtime error to avoid an infinite loop in the i/o reactor trying to flush buffered output Contributed by Dmitry Potapov <potapov.d at gmail.com> * [HTTPCORE-376] AbstractNIOConnPool#requestCancelled() should not process pending requests wnen being shut down. Contributed by Dmitry Potapov <potapov.d at gmail.com> * [HTTPASYNC-69]: async request handler is closed by HttpAsyncRequestExecutor#closed if the underlying connection is found to be in an inconsistent state. Contributed by Oleg Kalnichevski <olegk at apache.org> (In reply to David Williams from comment #9) > > And, you'll recall I mentioned their "httpclient OSGi bundle" included > everything ... hence, good example of why its important to do proper > componentization. I do not know if their "super client bundle" included > these fixes (they are not mentioned in release notes) ... perhaps "the > client" bundle doesn't need them? ... or, perhaps they will be coming out > with a 4.3.6 version of OSGi client soon to include them in their "super > bundle"!? > > I think I will not try to update these for M3, after all, and instead wait > to see what happens next. Might have to join their mailing list! And, > perhaps a reason not to try and use (and "hack up") their "OSGi bundle"? It does sound like there will be a 4.3.6 "client" soon? As that's the target of this bug: Problematic OSGi bundling https://issues.apache.org/jira/browse/HTTPCLIENT-1558 Though, can't say if their fix addresses main issue, or just avoids one specific problem mentioned. I did join httpcomponents mailing list, and have been discussing "OSGi" with them. https://mail-archives.apache.org/mod_mbox/hc-dev/201410.mbox/browser They definitely have a unique perspective on "how to make bundles" so my guess is that for Orbit, we will continue to make our own OSGi bundles "out of" their "plain 'ol java' jars, when though this may be a bit confusing "in the wild", if the two "sources" of bundles ever overlap. But, I did learn they do plan to come out with "4.3.6" soon (mostly to decouple the "core" component, from the "client" component), so at that time we'll update to 4.3.6 client, and 4.3.3 core. (In reply to David Williams from comment #11) > But, I did learn they do plan to come out with "4.3.6" soon (mostly to > decouple the "core" component, from the "client" component), so at that time > we'll update to 4.3.6 client, and 4.3.3 core. The hc project is voting on a release now, with an RC1 candidate, for 4.3.6. In release notes, it is mentioned "SSLv3 protocol is disabled by default" ... which, I sort of thought it was already, so not sure what they mean? Perhaps need a -D property to override, or something. https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-4.3.6-RC1/RELEASE_NOTES-4.3.x.txt I have opened Platform CQs for the 4.3.6 client: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8934 and the 4.3.3 core: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8938 These are now in Orbit (bug 453107) in I-build repo: http://download.eclipse.org/tools/orbit/downloads/drops/I20141129202728/repository/ I'd like to add to a build soon, but need to coordinate with features that need to be "touched" when third party jars change. I far as I can see, the only one is org.eclipse.equinox.server.p2 which is in the repository rt.equinox.bundles And, of course, in the ECF features, but since we merely 'require' those (not include) we can make our changes independently of ECF. ECF upgrade will be discussed in bug 448916. I have updated our prereqs for httpcomponents in eclipse-sdk-prereqs.target with the commit http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=c240aa4327aa55ada56f1b16fa22106cda188cea This should be fine for the "N-builds". If for some reason, org.eclipse.equinox.server.p2 can not be touched before I-build, then this can be "reverted" (or, I can additionally put back in "old versions" as well ... just to satisfy the build (though, honestly, not sure which would end up in out repo ... probably both?) (In reply to David Williams from comment #15) > If for some reason, org.eclipse.equinox.server.p2 can not be touched before > I-build, then this can be "reverted" (or, I can additionally put back in > "old versions" as well ... just to satisfy the build (though, honestly, not > sure which would end up in out repo ... probably both?) I've opened bug 453675 for the required equinox change. I'm going to count this as fixed, since "my" work is done, with what this bug was to do. But, we still have the older 4.3.4, 4.3.2 versions in our repository, and it is those that are "included" by the "equinox.server.p2" -- all presumably because ECF has not been updated yet. |