Community
Participate
Working Groups
i have groovy eclipse installed. i cannot remove it (see bug420855), so i left it. upgrading now fails with: Some sites could not be found. See the error log for more detail. HTTP Proxy Authentication Required: http://dist.springsource.org/snapshot/GRECLIPSE/e4.3/content.xml Proxy Authentication Required HTTP Proxy Authentication Required: http://download.eclipse.org/eclipse/updates/4.4/compositeContent.xml Proxy Authentication Required HTTP Proxy Authentication Required: http://download.eclipse.org/releases/luna/compositeContent.xml Proxy Authentication Required there is a proxy, which works for other things, and it has no authentication.
this happened while uninstalling greclipse, and a try to upgrade eclipse luna, see bug420855. the stacktrace !ENTRY org.eclipse.equinox.p2.core 4 0 2013-11-27 15:24:40.231 !MESSAGE Provisioning exception !STACK 1 org.eclipse.equinox.p2.core.ProvisionException: HTTP Proxy Authentication Required: http://download.eclipse.org/releases/luna/compositeContent.xml at org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:192) at org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepositoryFactory.getLocalFile(CompositeMetadataRepositoryFactory.java:73) at org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepositoryFactory.load(CompositeMetadataRepositoryFactory.java:98) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:668) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.doLoad(LoadMetadataRepositoryJob.java:117) at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.runModal(LoadMetadataRepositoryJob.java:102) at org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler$2.runModal(PreloadingRepositoryHandler.java:83) at org.eclipse.equinox.p2.operations.ProvisioningJob.run(ProvisioningJob.java:177) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) Caused by: org.eclipse.ecf.filetransfer.BrowseFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:291) at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) ... 1 more !SUBENTRY 1 org.eclipse.equinox.p2.transport.ecf 4 1002 2013-11-27 15:24:40.231 !MESSAGE HTTP Proxy Authentication Required: http://download.eclipse.org/releases/luna/compositeContent.xml !STACK 1 org.eclipse.ecf.filetransfer.BrowseFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:291) at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) !SUBENTRY 2 org.eclipse.ecf.identity 4 0 2013-11-27 15:24:40.231 !MESSAGE Proxy Authentication Required !ENTRY org.eclipse.equinox.p2.core 4 0 2013-11-27 15:24:43.819 !MESSAGE Provisioning exception !STACK 1 org.eclipse.equinox.p2.core.ProvisionException: HTTP Proxy Authentication Required: http://dist.springsource.org/snapshot/GRECLIPSE/e4.3/content.xml at org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:192) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory.java:66) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:88) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:668) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.doLoad(LoadMetadataRepositoryJob.java:117) at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.runModal(LoadMetadataRepositoryJob.java:102) at org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler$2.runModal(PreloadingRepositoryHandler.java:83) at org.eclipse.equinox.p2.operations.ProvisioningJob.run(ProvisioningJob.java:177) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) Caused by: org.eclipse.ecf.filetransfer.BrowseFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:291) at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) ... 1 more !SUBENTRY 1 org.eclipse.equinox.p2.transport.ecf 4 1002 2013-11-27 15:24:43.819 !MESSAGE HTTP Proxy Authentication Required: http://dist.springsource.org/snapshot/GRECLIPSE/e4.3/content.xml !STACK 1 org.eclipse.ecf.filetransfer.BrowseFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:291) at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) !SUBENTRY 2 org.eclipse.ecf.identity 4 0 2013-11-27 15:24:43.819 !MESSAGE Proxy Authentication Required
the proxy authentication is reported like this with "native" proxy config.
Seems like something resolved before (252002) shown up again. With the same proxy settings, it works on Kelpler, but not working on Luna 4.4 milestone build (including latest 4.4 M6). And workaround, like changing the eclipse.ini, does not work as well.
Same here with manual proxy configuration that works in Kepler and earlier releases. (Tested with Luna 4.4 M6 build)
I face the same problem using LUNA 4.4 M6 within our corporate network. Same proxy settings (native) work well with KEPLER. In LUNA I get also the http auth exception: org.eclipse.equinox.p2.core.ProvisionException: HTTP Proxy Authentication Required: http://download.eclipse.org/releases/luna/content.xml
Same issue here with DSL version. Luna M6 (eclipse-dsl-luna-M6-win32-x86_64) can't open Marketplace and can't install any software updates (org.eclipse.equinox.p2.core.ProvisionException: HTTP Proxy Authentication), while latest Kepler (eclipse-dsl-kepler-SR2-win32-x86_64) with SAME proxy settings is able to do it without any problems. Problem exist also in latest nighly build (eclipse-SDK-N20140409-2135-win32-x86_64).
Same issue here with Luna M7. Based on a fresh installation I did the proxy settings according exactly to how I did it in my already existing Kepler installation. Afterwards tried to acces the market place: Not possible. Message: Cannot open Eclipse Marketplace Cannot install remote marketplace locations: Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p Proxy Authentication Required Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p Proxy Authentication Required Additonally: Whenever I start Luna, I can see several messages in the problem's view saying "System property https.proxyPort is not set but should be 8080". Same message for the other usual proxy settings. The messages disappear after workspace build.
I know this issue also from SonarCube-Plugin on Kepler. As far as I know they suspect this to be a problem with incompatible versions of Apache http commons libraries in the plugins. See here: http://sonarqube.15.x6.nabble.com/sonar-dev-SonarQube-Plugin-3-3-0-breaks-Eclipse-Kepler-Service-Release-2-proxy-settings-td5022971.html
I have still the same problem with Eclipse Luna SDK RC3.
This problem remains with Eclipse luna RC4! After Menu Help / Search for updates, the error message is: Some sites could not be found. See the error log for more detail. HTTP Proxy Authentication Required: http://download.eclipse.org/releases/luna/content.xml Proxy Authentication Required HTTP Proxy Authentication Required: http://download.eclipse.org/eclipse/updates/4.4/content.xml Proxy Authentication Required In the error log, there are two info messages and several exceptions: System property https.proxyHost is set to [our proxy address] but should not be set. System property http.proxyPort is set to [our proxy port] but should not be set. The first two exception stack traces: 1.) org.eclipse.equinox.p2.core.ProvisionException: HTTP Proxy Authentication Required: http://download.eclipse.org/releases/luna/content.xml at org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:192) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory.java:66) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:88) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:668) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.doLoad(LoadMetadataRepositoryJob.java:117) at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.runModal(LoadMetadataRepositoryJob.java:102) at org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler$2.runModal(PreloadingRepositoryHandler.java:83) at org.eclipse.equinox.p2.operations.ProvisioningJob.run(ProvisioningJob.java:177) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: org.eclipse.ecf.filetransfer.BrowseFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:287) at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) ... 1 more 2.) org.eclipse.equinox.p2.core.ProvisionException: HTTP Proxy Authentication Required: http://download.eclipse.org/eclipse/updates/4.4/content.xml at org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:192) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory.java:66) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:88) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:668) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.doLoad(LoadMetadataRepositoryJob.java:117) at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.runModal(LoadMetadataRepositoryJob.java:102) at org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler$2.runModal(PreloadingRepositoryHandler.java:83) at org.eclipse.equinox.p2.operations.ProvisioningJob.run(ProvisioningJob.java:177) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: org.eclipse.ecf.filetransfer.BrowseFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:287) at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) ... 1 more The same network setting are working with Eclipse kepler. I am connected via a network proxy, but with no auth required. Eclipse luna would such be unsuable, because no features or plugins could be installed.
*** Bug 437506 has been marked as a duplicate of this bug. ***
This seems at least "major", since is a regression and "lost function" from previous releases. Reference in comment 8 seems to give some insight, and looking at our "repo report" see that someone somewhere is using an "older" version of httpcomponents: org.apache.httpcomponents.httpclient 4.2.6.v201311072007 4.1.3.v201209201135 org.apache.httpcomponents.httpcore 4.2.5.v201311072007 4.1.4.v201203221030 I know the platform and ECF use the higher version, but not sure who is using the lower version ... AND ... not sure how or why that lower version would get "priority" when ran? (If that is indeed the source of the problem). If that is the source of the problem, and if it is only "market place client" that uses the older version, then "market place client" could provide a patch feature to use the 4.2 version instead. But ... I am speculating based on skim reading some of the reports. A study of the "aggregation log" might reveal who's using what? https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel.luna.runaggregator/599/consoleFull
(In reply to David Williams from comment #12) > This seems at least "major", since is a regression and "lost function" from > previous releases. > > Reference in comment 8 seems to give some insight, and looking at our "repo > report" see that someone somewhere is using an "older" version of > httpcomponents: > > org.apache.httpcomponents.httpclient > 4.2.6.v201311072007 > 4.1.3.v201209201135 > > org.apache.httpcomponents.httpcore > 4.2.5.v201311072007 > 4.1.4.v201203221030 > > I know the platform and ECF use the higher version, but not sure who is > using the lower version ... AND ... not sure how or why that lower version > would get "priority" when ran? (If that is indeed the source of the > problem). I don't think the lower version would get priority. > > If that is the source of the problem, and if it is only "market place > client" that uses the older version, then "market place client" could > provide a patch feature to use the 4.2 version instead. Or they could install the Kepler feature patch (for Luna) that ECF provides in it's repo (and in the Luna repo). >But ... I am > speculating based on skim reading some of the reports. Right. > > A study of the "aggregation log" might reveal who's using what? > > https://hudson.eclipse.org/hudson/view/Repository%20Aggregation/job/simrel. > luna.runaggregator/599/consoleFull In the aggregator, is it possible to find out who/what else is pulling in 4.1 version of httpcomponents? ECF/platform is using 4.2. Older versions of Mylyn were using 4.1, but it's of course possible that other projects are using/including 4.1. For the people that are able to reproduce this problem (likely related to NTLM proxy support in apache httpcomponents versions): Could you provide a listing of all bundles that are present in the Eclipse installation that shows the problem? via with the OSGi console?
(In reply to Scott Lewis from comment #13) > > In the aggregator, is it possible to find out who/what else is pulling in > 4.1 version of httpcomponents? ECF/platform is using 4.2. Older versions > of Mylyn were using 4.1, but it's of course possible that other projects are > using/including 4.1. > > For the people that are able to reproduce this problem (likely related to > NTLM proxy support in apache httpcomponents versions): Could you provide a > listing of all bundles that are present in the Eclipse installation that > shows the problem? via with the OSGi console? I checked the console log from our last (RC4) aggregation, and it was EGit that was "pulling in" the 4.1.x versions of httpcomponents. But, then I checked both the "standard" package and the "Java EE" package, and they did not contain the 4.1.x versions, but instead the 4.2.x versions (as would be expected). So, definitely not from an "old" version of httpcomponents. Of course, that's not to say that 4.2.x does not have the problem. (In my quick read of some of the referenced links, I saw someone imply it was supposed to have been fixed in 4.2.x, but they questioned that, suggesting it was fixed in 4.3.x). So ... in conclusion ... I'm not sure there's much any of "us" can do without a lot more help from the community of people seeing this problem. The reason is, is that none of us access repositories though the types of proxies that are giving you trouble. I believe we need, at least, a) more information about the proxies? b) Or if any of these are "public" proxies we could use to try and recreate that'd be nice (but that seems unlikely) ... b) list of your "configuration" (available from "about box", Installation details, configuration tab).
(In reply to David Williams from comment #14) <stuff deleted> > I believe we need, at least, > > a) more information about the proxies? > > b) Or if any of these are "public" proxies we could use to try and recreate > that'd be nice (but that seems unlikely) ... > > b) list of your "configuration" (available from "about box", Installation > details, configuration tab). I would add to this list what was asked for in comment 13, i.e. for those that can reproduce the problem a list of the bundles running when the error occurs (i.e. via the OSGi console ss or status commands).
(In reply to Scott Lewis from comment #15) > (In reply to David Williams from comment #14) > <stuff deleted> > > I believe we need, at least, > > > > a) more information about the proxies? > > > > b) Or if any of these are "public" proxies we could use to try and recreate > > that'd be nice (but that seems unlikely) ... > > > > b) list of your "configuration" (available from "about box", Installation > > details, configuration tab). > > I would add to this list what was asked for in comment 13, i.e. for those > that can reproduce the problem a list of the bundles running when the error > occurs (i.e. via the OSGi console ss or status commands). Hi, I am able to reproduce the problem. I tried to use Luna but I couldn't connect to Marketplace. Follows the stacktrace and the content of my configuration box. I'm using Windows 7. I don't know if it can help you, but, here goes: !ENTRY org.eclipse.epp.mpc.ui 4 0 2014-06-26 15:30:28.694 !MESSAGE Cannot open Eclipse Marketplace !STACK 1 org.eclipse.core.runtime.CoreException: Cannot install remote marketplace locations: Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand.execute(MarketplaceWizardCommand.java:103) at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:294) at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132) at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:149) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.executeItem(HandledContributionItem.java:825) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.handleWidgetSelection(HandledContributionItem.java:701) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$6(HandledContributionItem.java:685) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$4.handleEvent(HandledContributionItem.java:613) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4172) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) Caused by: org.eclipse.core.runtime.CoreException: Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:148) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:93) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80) at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:43) at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$5.run(MarketplaceWizardCommand.java:276) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) Caused by: org.eclipse.core.runtime.CoreException: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.epp.internal.mpc.core.util.AbstractP2TransportFactory.invokeStream(AbstractP2TransportFactory.java:35) at org.eclipse.epp.internal.mpc.core.util.TransportFactory$1.stream(TransportFactory.java:107) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:128) ... 5 more Caused by: org.eclipse.ecf.filetransfer.IncomingFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.openStreams(HttpClientRetrieveFileTransfer.java:658) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:885) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576) at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:389) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.read(FileReader.java:240) at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:172) ... 12 more Contains: Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p org.eclipse.core.runtime.CoreException: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.epp.internal.mpc.core.util.AbstractP2TransportFactory.invokeStream(AbstractP2TransportFactory.java:35) at org.eclipse.epp.internal.mpc.core.util.TransportFactory$1.stream(TransportFactory.java:107) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:128) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:93) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80) at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:43) at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$5.run(MarketplaceWizardCommand.java:276) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) Caused by: org.eclipse.ecf.filetransfer.IncomingFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.openStreams(HttpClientRetrieveFileTransfer.java:658) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:885) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576) at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:389) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.read(FileReader.java:240) at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:172) ... 12 more !SUBENTRY 1 org.eclipse.epp.mpc.ui 4 0 2014-06-26 15:30:28.697 !MESSAGE Cannot install remote marketplace locations: Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p !STACK 1 org.eclipse.core.runtime.CoreException: Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:148) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:93) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80) at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:43) at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$5.run(MarketplaceWizardCommand.java:276) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) Caused by: org.eclipse.core.runtime.CoreException: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.epp.internal.mpc.core.util.AbstractP2TransportFactory.invokeStream(AbstractP2TransportFactory.java:35) at org.eclipse.epp.internal.mpc.core.util.TransportFactory$1.stream(TransportFactory.java:107) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:128) ... 5 more Caused by: org.eclipse.ecf.filetransfer.IncomingFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.openStreams(HttpClientRetrieveFileTransfer.java:658) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:885) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576) at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:389) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.read(FileReader.java:240) at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:172) ... 12 more !SUBENTRY 2 org.eclipse.epp.mpc.core 4 0 2014-06-26 15:30:28.697 !MESSAGE Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p !STACK 1 org.eclipse.core.runtime.CoreException: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.epp.internal.mpc.core.util.AbstractP2TransportFactory.invokeStream(AbstractP2TransportFactory.java:35) at org.eclipse.epp.internal.mpc.core.util.TransportFactory$1.stream(TransportFactory.java:107) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:128) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:93) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80) at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:43) at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$5.run(MarketplaceWizardCommand.java:276) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) Caused by: org.eclipse.ecf.filetransfer.IncomingFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.openStreams(HttpClientRetrieveFileTransfer.java:658) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:885) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576) at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:389) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.read(FileReader.java:240) at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:172) ... 12 more !SUBENTRY 3 org.eclipse.equinox.p2.transport.ecf 4 1002 2014-06-26 15:30:28.698 !MESSAGE HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p !STACK 1 org.eclipse.ecf.filetransfer.IncomingFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.openStreams(HttpClientRetrieveFileTransfer.java:658) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:885) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576) at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:389) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.read(FileReader.java:240) at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:172) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.epp.internal.mpc.core.util.AbstractP2TransportFactory.invokeStream(AbstractP2TransportFactory.java:35) at org.eclipse.epp.internal.mpc.core.util.TransportFactory$1.stream(TransportFactory.java:107) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:128) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:93) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80) at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:43) at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$5.run(MarketplaceWizardCommand.java:276) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) !SUBENTRY 4 org.eclipse.ecf.identity 4 0 2014-06-26 15:30:28.698 !MESSAGE Proxy Authentication Required !SUBENTRY 2 org.eclipse.epp.mpc.core 4 0 2014-06-26 15:30:28.698 !MESSAGE Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p !STACK 1 org.eclipse.core.runtime.CoreException: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.epp.internal.mpc.core.util.AbstractP2TransportFactory.invokeStream(AbstractP2TransportFactory.java:35) at org.eclipse.epp.internal.mpc.core.util.TransportFactory$1.stream(TransportFactory.java:107) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:128) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:93) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80) at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:43) at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$5.run(MarketplaceWizardCommand.java:276) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) Caused by: org.eclipse.ecf.filetransfer.IncomingFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.openStreams(HttpClientRetrieveFileTransfer.java:658) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:885) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576) at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:389) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.read(FileReader.java:240) at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:172) ... 12 more !SUBENTRY 3 org.eclipse.equinox.p2.transport.ecf 4 1002 2014-06-26 15:30:28.698 !MESSAGE HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p !STACK 1 org.eclipse.ecf.filetransfer.IncomingFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.openStreams(HttpClientRetrieveFileTransfer.java:658) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:885) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576) at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:389) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.read(FileReader.java:240) at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:172) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.epp.internal.mpc.core.util.AbstractP2TransportFactory.invokeStream(AbstractP2TransportFactory.java:35) at org.eclipse.epp.internal.mpc.core.util.TransportFactory$1.stream(TransportFactory.java:107) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:128) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:93) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80) at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:43) at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$5.run(MarketplaceWizardCommand.java:276) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) !SUBENTRY 4 org.eclipse.ecf.identity 4 0 2014-06-26 15:30:28.699 !MESSAGE Proxy Authentication Required
(In reply to Saulo Augusto from comment #16) > (In reply to Scott Lewis from comment #15) Continuing.... The content of the configuration box is too long, but, this seems to be a useful information according to the others comments: Id: org.apache.httpcomponents.httpclient, Version: 4.2.6.v201311072007, Location: reference:file:plugins/org.apache.httpcomponents.httpclient_4.2.6.v201311072007.jar Id: org.apache.httpcomponents.httpcore, Version: 4.2.5.v201311072007, Location: reference:file:plugins/org.apache.httpcomponents.httpcore_4.2.5.v201311072007.jar Please let me know if you need any other information. Tks.
(In reply to Saulo Augusto from comment #17) > (In reply to Saulo Augusto from comment #16) > > (In reply to Scott Lewis from comment #15) > > Continuing.... > > The content of the configuration box is too long, but, this seems to be a > useful information according to the others comments: > > Id: org.apache.httpcomponents.httpclient, Version: 4.2.6.v201311072007, > Location: > reference:file:plugins/org.apache.httpcomponents.httpclient_4.2.6. > v201311072007.jar > Id: org.apache.httpcomponents.httpcore, Version: 4.2.5.v201311072007, > Location: > reference:file:plugins/org.apache.httpcomponents.httpcore_4.2.5. > v201311072007.jar > > Please let me know if you need any other information. It would be helpful to have the entire output from the configuration box...perhaps you could attach to this bug rather than paste here? The reason this is important is that it's pretty clear to me that there are two version of httpclient 4 present...but what's not clear is how they got there, what ECF providers (that use them) are present, and what their state is (active or not) at runtime.
Created attachment 244564 [details] Configuration Box Content
(In reply to Saulo Augusto from comment #19) > Created attachment 244564 [details] > Configuration Box Content Thanks for providing this, but a quick search in my browser for 'org.apache.http' shows: org.apache.httpcomponents.httpclient (4.2.6.v201311072007) "Apache HttpComponents HttpClient OSGi bundle" [Resolved] org.apache.httpcomponents.httpcore (4.2.5.v201311072007) "Apache HttpComponents HttpCore" [Resolved] ... Id: org.apache.httpcomponents.httpclient, Version: 4.2.6.v201311072007, Location: reference:file:plugins/org.apache.httpcomponents.httpclient_4.2.6.v201311072007.jar Id: org.apache.httpcomponents.httpcore, Version: 4.2.5.v201311072007, Location: reference:file:plugins/org.apache.httpcomponents.httpcore_4.2.5.v201311072007.jar It seems to only be reporting the presence of httpclient 4.2.6 and httpcore 4.2.5...which is/are the appropriate Luna versions, and the older versions don't seem to be present. Further, the ECF provider versions present are also just the Luna ones (v20140528-1625). org.eclipse.ecf (3.4.0.v20140528-1625) "ECF Core API" [Active] org.eclipse.ecf.filetransfer (5.0.0.v20140528-1625) "ECF Filetransfer API" [Active] org.eclipse.ecf.identity (3.4.0.v20140528-1625) "ECF Identity Core API" [Active] org.eclipse.ecf.provider.filetransfer (3.2.200.v20140528-1625) "ECF Filetransfer Provider" [Active] org.eclipse.ecf.provider.filetransfer.httpclient4 (1.0.500.v20140528-1625) "ECF HttpComponents Filetransfer Provider" [Active] org.eclipse.ecf.provider.filetransfer.httpclient4.ssl (1.0.0.v20140528-1625) "ECF HttpComponents Filetransfer Provider" [Resolved] org.eclipse.ecf.provider.filetransfer.ssl (1.0.0.v20140528-1625) "ECF Filetransfer Provider" [Resolved] org.eclipse.ecf.ssl (1.1.0.v20140528-1625) "ECF Core API" [Resolved] Also...in this configuration the httpclient bundles are only resolved (not active)...meaning that they haven't been used yet. Could you reproduce the error and then get a snapshot of the configuration? Or rather than the configuration can you get the output of ss in the OSGi console? And if we can determine that this problem really is with 4.2.6 and 4.2.5 of httpclient/httpcore then the next question is: could you please try to reproduce this failure with Eclipse Luna rather than with the the marketplace client? The reason this would be helpful is that there are many more aids to diagnosing the problem in Eclipse Luna (e.g. easy access to the OSGi console). Thanks.
(In reply to Saulo Augusto from comment #19) > Created attachment 244564 [details] > Configuration Box Content I also just noticed this in your configuration: http.nonProxyHosts=localhost|127.0.0.1 http.proxyHost=proxy.pkk.com.br http.proxyPassword=******** http.proxyPort=8080 http.proxySet=true http.proxyUser=yyyy http.proxyUserName=yyyy https.nonProxyHosts=localhost|127.0.0.1 https.proxyHost=proxy.pkk.com.br https.proxyPassword=******** https.proxyPort=8080 https.proxySet=true https.proxyUser=yyyy https.proxyUserName=yyyy This may be problematic, given the marketplace client's use of the Eclipse proxy API...conveyed by the presence of this plugin: Id: org.eclipse.core.net, Version: 1.2.200.v20140124-2013, Location: reference:file:plugins/org.eclipse.core.net_1.2.200.v20140124-2013.jar Id: org.eclipse.core.net.win32.x86, Version: 1.0.100.v20140124-2013, Location: reference:file:plugins/org.eclipse.core.net.win32.x86_1.0.100.v20140124-2013.jar You also appear to have lots of proxy configuration setup in the user preferences (for example): /configuration/org.eclipse.core.net/proxyData/HTTPS/host=proxy.pkk.com.br (there are many more if one searches for 'org.eclipse.core.net'. All I'm suggesting is that with the https.* properties as above, and the proxy configuration in org.eclipse.core.net user configuration it seems possible this could be a configuration issue with this particular proxy type (NTLM I assume).
It seems a number of these reports are from "going through the Market Place Client (MPC)"? Or have I mis-read? In any case, for those of you trying to use MPC, I wanted to be sure you aware of bug 437844 ... and that a fix is available for it, directly from the mpc update site: http://download.eclipse.org/mpc/luna (In most case, you'd have to not only add that explicitly to your "available software sites", but even then "get updates" (probably) won't find it, but you'd have to go to "install new software" and select that repo, and then select mpc to be installed (and ... then you'll be told it's already installed, and update will be performed instead :) ... but, a different meaning of 'update'). Anyway, on the surface, that bug appears completely unrelated to this bug ... but ... it would not be the first time that one bug "manifests itself" with the wrong error message, under the right conditions. (And, if it did, that would still be a bug, but a) a bug of a different type, and b) if it magically fixes this "proxy issue" then at least there is a path forward for some of you. Just FYI ... in case it happens to help ... not that I would bet on it ... but seemed worth mentioning.
Saulo, thanks for providing the logs and configurations. One think I noticed was "VirtualBox" was on your path. Does that mean you are using a "virtual version of windows"? I ask simply wondering if everyone else experiencing the problem is also running on a "virtual machine"? If so, just thought it might provide a hint of areas to investigate (as well as a request to test on a non-virtualized machine ... if anyone was able to do that, on the same network). Thanks again,
Created attachment 244575 [details] Installation Details I've just installed the patch provided for the Market Place Client (using our local P2-Mirror, that, unfortunately, offers no real solution), but the mentioned issues still appear. Actually it is not possible to use any component (MPC, "Install new software", M2E-Plugin-Discovery etc.) that tries to access the internet via our NTLMv2-proxy. eclipse.buildId=4.4.0.I20140606-1215 java.version=1.7.0_45 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product org.eclipse.equinox.p2.core Error Fri Jun 27 08:36:17 CEST 2014 Provisioning exception org.eclipse.equinox.p2.core.ProvisionException: HTTP Proxy Authentication Required: http://download.eclipse.org/releases/luna/content.xml at org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:192) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory.java:66) at org.eclipse.equinox.internal.p2.metadata.repository.SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:88) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:668) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.doLoad(LoadMetadataRepositoryJob.java:117) at org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.runModal(LoadMetadataRepositoryJob.java:102) at org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler$2.runModal(PreloadingRepositoryHandler.java:83) at org.eclipse.equinox.p2.operations.ProvisioningJob.run(ProvisioningJob.java:177) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Caused by: org.eclipse.ecf.filetransfer.BrowseFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:287) at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) ... 1 more Thanks
(In reply to David Williams from comment #23) > Saulo, > > thanks for providing the logs and configurations. One think I noticed was > "VirtualBox" was on your path. Does that mean you are using a "virtual > version of windows"? I ask simply wondering if everyone else experiencing > the problem is also running on a "virtual machine"? > > If so, just thought it might provide a hint of areas to investigate (as well > as a request to test on a non-virtualized machine ... if anyone was able to > do that, on the same network). > > Thanks again, Hi David, I have VirtualBox installed, but, the host machine is running windows. My guest machine (virtualbox) is running Linux. I'm trying to run Luna on the windows machine.
(In reply to Daniel Götten from comment #24) > Created attachment 244575 [details] > Installation Details > > I've just installed the patch provided for the Market Place Client (using > our local P2-Mirror, that, unfortunately, offers no real solution), but the > mentioned issues still appear. Actually it is not possible to use any > component (MPC, "Install new software", M2E-Plugin-Discovery etc.) that > tries to access the internet via our NTLMv2-proxy. > > eclipse.buildId=4.4.0.I20140606-1215 > java.version=1.7.0_45 > java.vendor=Oracle Corporation > BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE > Framework arguments: -product org.eclipse.epp.package.jee.product > Command-line arguments: -os win32 -ws win32 -arch x86_64 -product > org.eclipse.epp.package.jee.product > > org.eclipse.equinox.p2.core > Error > Fri Jun 27 08:36:17 CEST 2014 > Provisioning exception > > org.eclipse.equinox.p2.core.ProvisionException: HTTP Proxy Authentication > Required: http://download.eclipse.org/releases/luna/content.xml > at > org.eclipse.equinox.internal.p2.repository.CacheManager. > createCache(CacheManager.java:192) > at > org.eclipse.equinox.internal.p2.metadata.repository. > SimpleMetadataRepositoryFactory.getLocalFile(SimpleMetadataRepositoryFactory. > java:66) > at > org.eclipse.equinox.internal.p2.metadata.repository. > SimpleMetadataRepositoryFactory.load(SimpleMetadataRepositoryFactory.java:88) > at > org.eclipse.equinox.internal.p2.metadata.repository. > MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57) > at > org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager. > loadRepository(AbstractRepositoryManager.java:768) > at > org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager. > loadRepository(AbstractRepositoryManager.java:668) > at > org.eclipse.equinox.internal.p2.metadata.repository. > MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96) > at > org.eclipse.equinox.internal.p2.metadata.repository. > MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) > at > org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob. > doLoad(LoadMetadataRepositoryJob.java:117) > at > org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob. > runModal(LoadMetadataRepositoryJob.java:102) > at > org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler$2. > runModal(PreloadingRepositoryHandler.java:83) > at > org.eclipse.equinox.p2.operations.ProvisioningJob.run(ProvisioningJob.java: > 177) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) > Caused by: org.eclipse.ecf.filetransfer.BrowseFileTransferException: Proxy > Authentication Required > at > org.eclipse.ecf.provider.filetransfer.httpclient4. > HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:287) > at > org.eclipse.ecf.provider.filetransfer.browse. > AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) > ... 1 more > > Thanks Here I have exactly the same scenario. Nothing that tries to access the internet via proxy works (Marketplace, Update Site, etc).
Seems like the cause of the problem is http components version. I just removed the 4.2.x version jars from the plugins folder and put the kepler's version 4.1.x, now, everything works fine. I can use Marketplace, Update Site e etc.
(In reply to Saulo Augusto from comment #27) > Seems like the cause of the problem is http components version. I just > removed the 4.2.x version jars from the plugins folder and put the kepler's > version 4.1.x, now, everything works fine. I can use Marketplace, Update > Site e etc. Could you attach your configuration? Thanks. Would you be willing to try to reproduce the problem on Eclipse Luna? (which also uses 4.2.x) versions of http components?
I have removed : org.eclipse.ecf.provider.filetransfer.httpclient4.ssl_1.0.0.v20140528-1625.jar org.eclipse.ecf.provider.filetransfer.httpclient4_1.0.500.v20140528-1625.jar org.eclipse.ecf.provider.filetransfer.ssl_1.0.0.v20140528-1625.jar and everything appears to work fine; no more exceptions of the sort "Proxy access denied" appear :)
(In reply to Stephan Undisclosed from comment #29) > I have removed : > > org.eclipse.ecf.provider.filetransfer.httpclient4.ssl_1.0.0.v20140528-1625. > jar > org.eclipse.ecf.provider.filetransfer.httpclient4_1.0.500.v20140528-1625.jar > org.eclipse.ecf.provider.filetransfer.ssl_1.0.0.v20140528-1625.jar > > and everything appears to work fine; no more exceptions of the sort "Proxy > access denied" appear :) How did you remove them? If this is actually the case, I don't really know what the marketplace client is doing.
just went to eclipse-folder plugins and deleted them; then restart eclipse...
(In reply to Scott Lewis from comment #28) > (In reply to Saulo Augusto from comment #27) > > Seems like the cause of the problem is http components version. I just > > removed the 4.2.x version jars from the plugins folder and put the kepler's > > version 4.1.x, now, everything works fine. I can use Marketplace, Update > > Site e etc. > > Could you attach your configuration? Thanks. > > Would you be willing to try to reproduce the problem on Eclipse Luna? > (which also uses 4.2.x) versions of http components? I'm on Eclipse Luna. I replaced the http components 4.2.x of my Eclipse Luna with the 4.1.x jars from Kepler, and now works fine. I'll attach my ss from osgi console.
Created attachment 244599 [details] ss osgi console http components 4.2.x replaced with 4.1.x
I believe that in both of these cases...i.e. Stephan and Saulo, what's happening is that by removing or replacing any of these bundles (org.apache.httpcomponent.* 4.2.x or the associated provider) that you are basically disabling the 4.2.x implementation and so ECF filetransfer falls back to using the JRE-provider...i.e. based upon HttpURLConnection. And in your environment this JRE-based provider works. I don't actually think this shows definitively that this is a problem with the httpcomponents 4.2 impl (relative to httpcomponents 4.1), although that is possible. Incidently, you can disable any ECF filetransfer provider by setting a system property (rather than removing the jar). See here: https://wiki.eclipse.org/Disabling_Apache_Httpclient I'm not really sure how p2 will respond to removing or replacing jars on the filesystem, so I wouldn't suggest doing a lot of that as it make create an unworkable environment. Since this problem seems limited to the MPC (not Eclipse update so far), I still suspect some problem or interaction with the proxy configuration on MPC.
(In reply to Scott Lewis from comment #34) > I believe that in both of these cases...i.e. Stephan and Saulo, what's > happening is that by removing or replacing any of these bundles > (org.apache.httpcomponent.* 4.2.x or the associated provider) that you are > basically disabling the 4.2.x implementation and so ECF filetransfer falls > back to using the JRE-provider...i.e. based upon HttpURLConnection. And in > your environment this JRE-based provider works. > > I don't actually think this shows definitively that this is a problem with > the httpcomponents 4.2 impl (relative to httpcomponents 4.1), although that > is possible. > > Incidently, you can disable any ECF filetransfer provider by setting a > system property (rather than removing the jar). See here: > > https://wiki.eclipse.org/Disabling_Apache_Httpclient > > I'm not really sure how p2 will respond to removing or replacing jars on the > filesystem, so I wouldn't suggest doing a lot of that as it make create an > unworkable environment. > > > Since this problem seems limited to the MPC (not Eclipse update so far), I > still suspect some problem or interaction with the proxy configuration on > MPC. When Http Client is enabled, nothing that uses proxy works for me. (Eclipse update, Install new software, Marketplace). Disabling it, everything works fine.
(In reply to Saulo Augusto from comment #35) <stuff deleted> > > When Http Client is enabled, nothing that uses proxy works for me. (Eclipse > update, Install new software, Marketplace). Disabling it, everything works > fine. Ok, great. Then at least you and others experiencing this proxy problem have a workaround (disabling httpclient). Returning to diagnosis, I would say the problem you and others are experiencing are likely one of: 1) Some regression wrt ntlm proxing in httpcomponents 4.2.x 2) Some configuration problem...e.g. the use of http.* properties along with the org.eclipse.core.net proxy configuration (i.e. proxy preferences in mpc/Eclipse) 3) Some interaction between 1 and 2 I'm currently favoring 2, but would like to collect as much info as possible from those of you that are experiencing the problem. Thanks for the configuration and installation details...that helps a lot, and I will try to use that info as much as possible to diagnose. I would, however, like to enlist your help further in diagnosing and fixing this issue, since I/we can't even create a proxy environment that allows me to reproduce this problem. It may be helpful at some point for me to speak or correspond directly with one or several of those that are experiencing this issue, to more quickly collect diagnostic information. Would this be possible for some of you?
I could provide some diagnostic data, but I won't be back in office before the end of July. I will then look into this thread again. Matthias
(In reply to Scott Lewis from comment #36) > (In reply to Saulo Augusto from comment #35) > <stuff deleted> > > > > When Http Client is enabled, nothing that uses proxy works for me. (Eclipse > > update, Install new software, Marketplace). Disabling it, everything works > > fine. > > Ok, great. Then at least you and others experiencing this proxy problem > have a workaround (disabling httpclient). > > Returning to diagnosis, I would say the problem you and others are > experiencing are likely one of: > > 1) Some regression wrt ntlm proxing in httpcomponents 4.2.x > 2) Some configuration problem...e.g. the use of http.* properties along with > the org.eclipse.core.net proxy configuration (i.e. proxy preferences in > mpc/Eclipse) > 3) Some interaction between 1 and 2 > > I'm currently favoring 2, but would like to collect as much info as possible > from those of you that are experiencing the problem. Thanks for the > configuration and installation details...that helps a lot, and I will try to > use that info as much as possible to diagnose. > > I would, however, like to enlist your help further in diagnosing and fixing > this issue, since I/we can't even create a proxy environment that allows me > to reproduce this problem. It may be helpful at some point for me to speak > or correspond directly with one or several of those that are experiencing > this issue, to more quickly collect diagnostic information. Would this be > possible for some of you? I can help you reproducing the problem and providing diagnostic information.
*** Bug 437014 has been marked as a duplicate of this bug. ***
*** Bug 420854 has been marked as a duplicate of this bug. ***
Adding bug 423196 for history/reference.
*** Bug 429879 has been marked as a duplicate of this bug. ***
*** Bug 438530 has been marked as a duplicate of this bug. ***
I tried the workaround and still no joy using the JRE HttpURLConnection method. This is what I put in my 4.4 eclipse.ini file in the vmargs section: -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4 I cannot check for updates nor use Eclipse Marketplace. I work in ubuntu 12.04 inside a VirtualBox VM on Windows 7 host. Kepler did not work on Native setting but when set to Manual I could successfully check for updates and use the marketplace through our proxy. Luna does not work on Native or Manual through our proxy. Based on this experience I'd concur that the problem is not with the apache/JRE http connection libraries but with configuration somewhere. I don't know how common this is but we won't be able to migrate to eclipse luna in our workplace till this is resolved either with a fix or a workaround.
(In reply to Dave Moten from comment #44) > I tried the workaround and still no joy using the JRE HttpURLConnection > method. > > This is what I put in my 4.4 eclipse.ini file in the vmargs section: > -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf. > provider.filetransfer.httpclient4 My best guess about why the workaround isn't working for you is that along with disabling the httpclient4, you have to also set the the appropriate JRE proxy settings...e.g. System.getProperties().put("http.proxyHost", "someProxyURL"); System.getProperties().put("http.proxyPort", "someProxyPort"); System.getProperties().put("http.proxyUser", "someUserName"); System.getProperties().put("http.proxyPassword", "somePassword"); Of course, the appropriate properties and values depend upon the type of proxy and it's configuration (i.e. whether and what proxy authentication is expected/done). If people who are experiencing the problem have the information, it would be very helpful to report the type of proxy you have and whether it has authentication or not. This would help narrow down the configuration issues (e.g. NTLMv2 proxies that require authentication). Thanks.
(In reply to Scott Lewis from comment #45) > System.getProperties().put("http.proxyHost", "someProxyURL"); > System.getProperties().put("http.proxyPort", "someProxyPort"); > System.getProperties().put("http.proxyUser", "someUserName"); > System.getProperties().put("http.proxyPassword", "somePassword"); Sorry, I should have pasted these in as system properties set on the command line rather than as java code...e.g. -Dhttp.proxyHost=someProxyURL -Dhttp.proxyPort=someProxyPort -Dhttp.proxyUser=someUserName -Dhttp.proxyPassword=somePassword
More background and reference for this bug: http://hc.apache.org/httpcomponents-client-4.4.x/ntlm.html This page describes the ntlm proxy support in httpclient 4.2.*. My suspicion is that this bug could be related to ntlm proxying, so it would be very helpful if those that are experiencing this problem could report: a) Whether it's an ntlm proxy that they are using (if not, then what type?) b) If it is an ntlm proxy, what version of ntlm is being used c) If ntlm, what version of windows proxy server
(In reply to Scott Lewis from comment #46) > Sorry, I should have pasted these in as system properties set on the command > line rather than as java code...e.g. > > -Dhttp.proxyHost=someProxyURL -Dhttp.proxyPort=someProxyPort > -Dhttp.proxyUser=someUserName -Dhttp.proxyPassword=somePassword We have tried these parameters, but this does also not work with our proxy.
(In reply to Scott Lewis from comment #47) > More background and reference for this bug: > > http://hc.apache.org/httpcomponents-client-4.4.x/ntlm.html > > This page describes the ntlm proxy support in httpclient 4.2.*. > > My suspicion is that this bug could be related to ntlm proxying, so it would > be very helpful if those that are experiencing this problem could report: > > a) Whether it's an ntlm proxy that they are using (if not, then what type?) > b) If it is an ntlm proxy, what version of ntlm is being used We are using NTLMv2. > c) If ntlm, what version of windows proxy server I have no idea how to check it at client side.
Hi, First let me say that I fixed the problem by deleting the 3 jars as described by Stephan above: org.eclipse.ecf.provider.filetransfer.httpclient4.ssl_1.0.0.v20140528-1625.jar org.eclipse.ecf.provider.filetransfer.httpclient4_1.0.500.v20140528-1625.jar org.eclipse.ecf.provider.filetransfer.ssl_1.0.0.v20140528-1625.jar As to NTLM version we're running a Cisco IronPort S170 Web Security Appliance running AsyncOS 7.5.1-201. It is configured to accept the NTLM protocol with NTLMSSP or Basic schemes. I haven't been able to find the version though. Best regards, Andrei
Hi Andrei, (In reply to andrei@lenkei.com Andrei Lenkei from comment #51) > Hi, > > First let me say that I fixed the problem by deleting the 3 jars as > described by Stephan above: > > > org.eclipse.ecf.provider.filetransfer.httpclient4.ssl_1.0.0.v20140528-1625. > jar > > org.eclipse.ecf.provider.filetransfer.httpclient4_1.0.500.v20140528-1625.jar > org.eclipse.ecf.provider.filetransfer.ssl_1.0.0.v20140528-1625.jar Although I'm glad this worked for you, things might be more stable for you if you used the workaround described in comment 34 instead of physically deleting the jars. Short explanation: ECF has a provider architecture, and there are two http filetransfer providers present: httpclient4 and one based upon jre urlconnection. When you delete the httpclient4 jars it falls back on the jre provider...and happily that works in your environment. The reason why it's risky to delete jars is that p2 provides a managed environment for plugins/bundles, and deleting the jars can put the p2 meta-data into an inconsistent state, possibly making it difficult or impossible to do other provisioning operations. Thanks for the info about your proxy environment. A couple of questions: 1) Does Kepler work in your proxy environment? 2) Would you be willing to attach your configuration to this bug? (after redacting password info if present) With respect to 1, if there's sufficient evidence that httpclient 4.1.x (Kepler) works for enough people experiencing this problem, I'm considering creating a new provider that downshifts versions and uses apache httpclient 4.1.x rather than 4.2.x.
First, sorry for the double post earlier. Deleting was faster than comment 34,I will re-install the jars and try #34. Yes, Kepler works with a problem, only Luna has issues. I'm sorry but it is not clear to me which configuration you mean. If you can tell me exactly which configuration (proxy?) and from which file I can extract it I'll be happy to attach it. Regards, Andrei
Hello, i've tested the workaround from comment 35 and it works! So we've added the line to eclipse.ini: -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4 We are using NTLMv2 proxy and it worked with Kepler. Thank You! Regards, Andre
(In reply to andrei@lenkei.com Andrei Lenkei from comment #53) > First, sorry for the double post earlier. > > Deleting was faster than comment 34,I will re-install the jars and try #34. > > Yes, Kepler works with a problem, only Luna has issues. > > I'm sorry but it is not clear to me which configuration you mean. If you can > tell me exactly which configuration (proxy?) and from which file I can > extract it I'll be happy to attach it. > > Regards, > Andrei I meant to say Kepler works withOUT a problem! ;-)
(In reply to andrei@lenkei.com Andrei Lenkei from comment #53) <stuff deleted> > I'm sorry but it is not clear to me which configuration you mean. If you can > tell me exactly which configuration (proxy?) and from which file I can > extract it I'll be happy to attach it. The configuration I was referring to is accessed in Eclipse by Help->About Eclipse SDK->Installation Details->Configuration tab If you could copy the whole thing and attach as txt file that would be great. Please be sure to redact any password info if present in the configuration. It might also be helpful to describe any proxy configuration (Network Connection preferences) you have set up...i.e. Active Provider...e.g. Native, Manual, or Direct, and any other info present. Thanks.
Created attachment 244832 [details] Eclipse config
I've created an updated version of the ECF httpclient4 provider that uses Apache Httpclient 4.1 (used in Kepler) rather than Apache Httpclient 4.2 (used in Luna and the apparent source of this regression). For those that are experiencing this proxy problem, this update may allow you to use your proxy, especially if Kepler (Apache 4.1) install/update worked for you. If it *does* work in some of your environments, then it would suggest that the problem is not with proxy configuration, but rather with Apache httpclient 4.2 deployed as part of Luna. OTOH if this does not fix things for you, then it may very well be a configuration issue. Disclaimer: Installing this update, and going back to using an older version of httpclient4, could break other plugins. Even if it works in your environment, please do not use it in a production environment unless you are quite sure that nothing else is broken by it (e.g. Mylyn). Also, this repo is not signed so please do not redistribute it. If you are not experiencing any problem wrt this bug, please do not install it. People on this bug who install and try this in their proxy environment please report back with what happens via a new comment on this bug. Since I do not have an environment to reproduce this apparent httpclient4 version-specific problem, I must depend upon people on this bug that do have such an environment for diagnosis. Instructions for installation: 1) Download this zip: http://download.eclipse.org/rt/ecf/httpclient4/org.eclipse.ecf.provider.httpclient4_3.9.0.zip 2) Unzip the contents to your local disk 3) Start Eclipse Luna. 4) Choose Help->Install New Software->Add... 5) Name: ECF 3.9.0 Httpclient4 Update 6) Select Local... button on right and navigate your local filesystem to where you unzipped the contents to in step 2 7) Navigate into the <unzip location>/archive/site.p2 directory and choose OK 8) There should be a single 'Uncategorized' item in the user Install dialog. Select this check box (and all sub-items) 9) Choose Next and step through the remaining wizard pages to finish the install 10) Restart Eclipse when prompted Then please try to install something into Eclipse. Whether this works for you or not, it would be helpful for you to report your experiences here with as much detail as possible. Thanks.
I can confirm that the updated ECF works! Just to make sure my earlier removal of the jars was not affecting anything in any way I downloaded a fresh Luna C++, gave it a new workspace and tried both normal installing and through the market place, neither worked. I then installed the updated version of ECF, restarted and everything worked! I did not make any settings changes at all. So it does seem like it is a httpclient4 version-specific problem. Best regards, Andrei
It worked for me too. I just installed in a fresh Luna and everything works fine. Thanks!
Thanks Saulo and Andrei for reporting your results. It would be valuable for others that are experiencing this problem to also verify that this 'reverse update' (going back to httpclient 4.1) allows them to successfully use their proxy. Please also report any results as a comment here. It would also be very helpful if p2/Platform/Mylyn/other projects could arrange for this reverse update to be more completely tested in other proxy environments prior to the service release, in order to make sure that 4.1 does not cause regression in other ways unrelated to this bug. Unfortunately the automated tests are not helpful because this httpclient4 regression appears to be specific to ntlmv2 proxy environments.
(In reply to Scott Lewis from comment #61) > Thanks Saulo and Andrei for reporting your results. > > It would be valuable for others that are experiencing this problem to also > verify that this 'reverse update' (going back to httpclient 4.1) allows them > to successfully use their proxy. Please also report any results as a > comment here. > > It would also be very helpful if p2/Platform/Mylyn/other projects could > arrange for this reverse update to be more completely tested in other proxy > environments prior to the service release, in order to make sure that 4.1 > does not cause regression in other ways unrelated to this bug. > Unfortunately the automated tests are not helpful because this httpclient4 > regression appears to be specific to ntlmv2 proxy environments. Several comments: 1) I'd prefer to at least try to "move up" instead of "moving back" (for Luna SR1). I notice, for example, there is at least one bug fixed in "4.3.3" that sounds related: https://issues.apache.org/jira/browse/HTTPCLIENT-1457 [HttpClientBuilder.useSystemProperties() is incompatible with NTLM scheme] (And, they have released 4.3.4 as of right now). 1B) It seems the bug mentioned above is specific to Windows (at least, as described). Are there any users having this issue on Linux, or Macs, or could any of those effected temporarily gain access to such a machine to give a quick test (of "original", is what I'm thinking, right now -- since if that works, it would sounds more feasible that 4.3.x would fix the issue on Windows and all would be well at the higher version. 2) Tiny issue with your logic that if it works with 4.4.1, then could not be a proxy configuration issue. While I do not think it is a proxy configuration issue ... at times a "fix" in one bit of code can expose a bug in another bit of code ... it doesn't mean we should continue to live with the lower level, just to work around someone else bug (though, that is a temporary possibility) -- But, like I said ... I don't think that is a configuration issue here ... just a general warning. [What would _really_ be nice, is if the apache httpclient/core components had some test suites that can be ran (or modified to run?) in the submitters environment, to see if there is a more direct test of "broken in httpclient 4.2.x but fixed 4.3.x"? 3) As for: "... would also be very helpful if p2/Platform/Mylyn/other projects could arrange for this reverse update to be more completely tested in other proxy environments prior to the service release" Not sure what "we" could do here, that you could not ... that is, you could ask webmasters to set up a one or more "test proxy" connections and have unit tests that would make sure your code (and p2) worked there. But, by all means, the work you've done so far is fantastically good news, and your efforts much appreciated -- by me, as well as all the uses who were having the problem. Thank you very much for that.
(In reply to David Williams from comment #62) <stuff deleted> > > Several comments: > > 1) I'd prefer to at least try to "move up" instead of "moving back" (for > Luna SR1). I notice, for example, there is at least one bug fixed in "4.3.3" > that sounds related: > > https://issues.apache.org/jira/browse/HTTPCLIENT-1457 > [HttpClientBuilder.useSystemProperties() is incompatible with NTLM scheme] > > (And, they have released 4.3.4 as of right now). Some resources will have to be identified to do this work and the associated testing. Even given the above bug fix, I think it likely that the problematic ntlm changes in 4.2 may very well carry through to 4.3+. <stuff deleted> > > 2) Tiny issue with your logic that if it works with 4.4.1, then could not be > a proxy configuration issue. I didn't say that. With 4.1 working for at least some of the people experiencing this problem, I just think it's less likely to be a configuration issue. There can/could always be multiple issues...although I think this somewhat unlikely because nothing changed in ECF from Kepler to Luna wrt proxy config, and AFAIK nothing changed in the platform proxy API either. >While I do not think it is a proxy > configuration issue ... at times a "fix" in one bit of code can expose a bug > in another bit of code ... it doesn't mean we should continue to live with > the lower level, just to work around someone else bug (though, that is a > temporary possibility) -- But, like I said ... I don't think that is a > configuration issue here ... just a general warning. [What would _really_ be > nice, is if the apache httpclient/core components had some test suites that > can be ran (or modified to run?) in the submitters environment, to see if > there is a more direct test of "broken in httpclient 4.2.x but fixed 4.3.x"? Yes it would be nice. > > 3) As for: "... would also be very helpful if p2/Platform/Mylyn/other > projects could arrange for this reverse update to be more completely tested > in other proxy environments prior to the service release" > > Not sure what "we" could do here, that you could not ... that is, you could > ask webmasters to set up a one or more "test proxy" connections and have > unit tests that would make sure your code (and p2) worked there. Sure I could ask, but that's a lot of work for me that I'm not currently able to commit to...at least without some help (as requested of platform/p2 or Mylyn teams) or direct support.
(In reply to Scott Lewis from comment #58) > Then please try to install something into Eclipse. Whether this works for > you or not, it would be helpful for you to report your experiences here with > as much detail as possible. It worked for us to. We are using Microsoft ISA server 2006 as Internet Proxy, configured by default with NTLMv2. Thanks, Tiago
(In reply to Scott Lewis from comment #58) > Then please try to install something into Eclipse. Whether this works for > you or not, it would be helpful for you to report your experiences here with > as much detail as possible. It works for us too. We are using Microsoft ISA with NTLMv2. Thanks, Andre
For those enjoying following this bug, I've opened bug 440265 to get a little wider audience for possible solutions for a future release. (And some of those alternatives might depend on some of you "early testers" testing some possibilities with some other feature patches! :)
(In reply to David Williams from comment #66) > For those enjoying following this bug, I've opened bug 440265 to get a > little wider audience for possible solutions for a future release. > > (And some of those alternatives might depend on some of you "early testers" > testing some possibilities with some other feature patches! :) We'll continue to work on this, but seems less and less likely to be in time for Luna SR1. (Just keeping everyone informed). And even then, such as if only fixed for Mars, I can not understate the importance of early testing by the community. And, educating us :) I wanted to clarify the actual problem. It sounds like, in summary, people are saying "there is a proxy, and it has no authentication", but Eclipse fails the update thinking that authentication is required. So, my question is ... is it literally "no authentication required" or, is it that these types of proxy servers get their "authentication" in some transparent way (such as certificates, ldap servers, mac addresses, "Active Directory" (what ever that is) ... or some other method?) You can see by my question how little I know about proxy servers, so ... that's why I'm asking. If/when we found someone capable of setting up a "test environment", I want to be sure it realistically reflects the type of environments you all are working with. Thanks for your help.
(In reply to David Williams from comment #67) > So, my question is ... is it literally "no authentication required" It is. I recently switched to luna... for some days everything worked fine including updates via our proxy, so I switched my productive environment to luna. But all at once, after having installed some plugins and plugin updates, network access via proxy didn't work... :-/
> So, my question is ... is it literally "no authentication required" or, is > it that these types of proxy servers get their "authentication" in some > transparent way (such as certificates, ldap servers, mac addresses, "Active > Directory" (what ever that is) ... or some other method?) You can see by my > question how little I know about proxy servers, so ... that's why I'm > asking. If/when we found someone capable of setting up a "test environment", In our environment the proxy authentification is handled via NTLM protocol.
(In reply to Frank Reifenstahl from comment #68) > (In reply to David Williams from comment #67) > > > So, my question is ... is it literally "no authentication required" > > It is. > > I recently switched to luna... for some days everything worked fine > including updates via our proxy, so I switched my productive environment to > luna. But all at once, after having installed some plugins and plugin > updates, network access via proxy didn't work... :-/ That's interesting. If you can duplicate this, and keep track of what you installed/updated (preferably one thing at a time) that might help us narrow down the issue. But sounds like others see it with a fresh install ... so obviously is complicated.
(In reply to Jan-Paul Nachtwey from comment #69) > In our environment the proxy authentification is handled via NTLM protocol. Ok, thanks. I do not know what that means, exactly. Perhaps its obvious to those that know about NTLM proxies, but if I had to guess, I'd guess there's more than one way the proxy could be set up to authenticate, using that protocol? I'll certainly research on my own, as I have time, but the more details we have, the better the odds of getting this fixed/tested.
(In reply to David Williams from comment #71) > > I'll certainly research on my own, as I have time, but the more details we > have, the better the odds of getting this fixed/tested. At the risk of stating the obvious, I want to emphasize David's point. A key-but-difficult thing about this bug is isolating what's going wrong in environments that are seeing this...especially given 1) Everyone's network environment has small-but-very-important differences (e.g. different versions of NTLM proxies, different proxy configurations, different authentication configuration options) 2) Eclipse installs vary widely (e.g. what addons they have, how they initially installed Eclipse, what other Java-based software they have configured for proxy, how the proxy is configured, etc). 3) Understanding the interaction between the configuration and the changes to NTLM proxy support in httpclient 4.2, given that we/I don't maintain httpclient and so don't know what exactly was done between 4.1 (which seems to work for many...see comment 58 ...and httpclient 4.2. 4) There is no availability (to me anyway) of test environment that allows us to reproduce what you are experiencing. This makes it much more difficult to reproduce the issue, and determine what's going on. In summary, the more details the better about 1 and 2 (and 3 if you have that information). In fact, if some of you are willing, it might be helpful for you to coordinate directly with me, David, and others who work on this bug.
(In reply to Scott Lewis from comment #58) Eclipse check for updates works for me after setting Preferences->NetworkConnections to Native. Eclipse Marketplace show components, but I can not search for "oracle" or "OEPE", which gives a timeout recceiving data. However using "browse for more soulutions" link gives me Eclipse marketplace in the Eclipse WEB browser. Using this I am able to search for "OEPE" and by klicking the "External install button" - I am able to install features.
I've just verified Luna SR1 RC1, it does not work with clean install and workspace. The workaround with adding "-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4" to eclipse.ini works. We are using Microsoft ISA with NTLMv2. Any plans to fix this for Luna SR1 release?
I can confirm that the workaround with the "excludeContributors" property works, but I've been reported that other parts of the application stop working then, in particular the access to the Eclipse Marketplace (REST) API. I wasn't able to verify this myself yet, but thought I would bring it up here.
(In reply to Andre Bossert from comment #74) > I've just verified Luna SR1 RC1, it does not work with clean install and > workspace. The workaround with adding > "-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf. > provider.filetransfer.httpclient4" to eclipse.ini works. > > We are using Microsoft ISA with NTLMv2. Any plans to fix this for Luna SR1 > release? I'm glad the work around works for you. And, no, no plans to fix for Luna SR1. Only, it'd be more accurate to say "no ability" to fix for Luna SR1. See comment 67 and comment 72. A high quality patch or convincing diagnostic data would be more appreciated. (And, that's not to say we've "given up" on fixing it ... but will at best be a very long time, with out a NTLMv2 or proxy expert.)
New installation of Luna on windows 7 64bit. Network configuration with proxy - working correctly. Try to use Eclipse Marketplace: !ENTRY org.eclipse.core.net 1 0 2014-08-28 09:47:15.193 !MESSAGE System property http.proxyHost is set to px.lukas but should not be set. !ENTRY org.eclipse.core.net 1 0 2014-08-28 09:47:15.214 !MESSAGE System property http.proxyPort is set to 8080 but should not be set. !ENTRY org.eclipse.core.net 1 0 2014-08-28 09:47:15.218 !MESSAGE System property https.proxyHost is set to px.lukas but should not be set. !ENTRY org.eclipse.core.net 1 0 2014-08-28 09:47:15.222 !MESSAGE System property https.proxyPort is set to 8080 but should not be set. !ENTRY org.eclipse.epp.mpc.ui 4 0 2014-08-28 09:55:05.217 !MESSAGE Cannot open Eclipse Marketplace !STACK 1 org.eclipse.core.runtime.CoreException: Cannot install remote marketplace locations: Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand.execute(MarketplaceWizardCommand.java:103) at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:294) at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:90) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:55) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:247) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:229) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:132) at org.eclipse.e4.core.commands.internal.HandlerServiceHandler.execute(HandlerServiceHandler.java:149) at org.eclipse.core.commands.Command.executeWithChecks(Command.java:499) at org.eclipse.core.commands.ParameterizedCommand.executeWithChecks(ParameterizedCommand.java:508) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:210) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.executeItem(HandledContributionItem.java:825) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.handleWidgetSelection(HandledContributionItem.java:701) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem.access$6(HandledContributionItem.java:685) at org.eclipse.e4.ui.workbench.renderers.swt.HandledContributionItem$4.handleEvent(HandledContributionItem.java:613) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4353) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1061) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4172) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3761) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1151) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1032) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:148) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:636) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:579) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:135) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:236) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:648) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:603) at org.eclipse.equinox.launcher.Main.run(Main.java:1465) Caused by: org.eclipse.core.runtime.CoreException: Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:148) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:93) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80) at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:43) at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$5.run(MarketplaceWizardCommand.java:276) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) Caused by: org.eclipse.core.runtime.CoreException: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.epp.internal.mpc.core.util.AbstractP2TransportFactory.invokeStream(AbstractP2TransportFactory.java:35) at org.eclipse.epp.internal.mpc.core.util.TransportFactory$1.stream(TransportFactory.java:107) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:128) ... 5 more Caused by: org.eclipse.ecf.filetransfer.IncomingFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.openStreams(HttpClientRetrieveFileTransfer.java:658) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:885) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576) at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:389) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.read(FileReader.java:240) at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:172) ... 12 more Contains: Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p org.eclipse.core.runtime.CoreException: HTTP Proxy Authentication Required: http://marketplace.eclipse.org/catalogs/api/p at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.epp.internal.mpc.core.util.AbstractP2TransportFactory.invokeStream(AbstractP2TransportFactory.java:35) at org.eclipse.epp.internal.mpc.core.util.TransportFactory$1.stream(TransportFactory.java:107) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:128) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:93) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80) at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:43) at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$5.run(MarketplaceWizardCommand.java:276) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) Caused by: org.eclipse.ecf.filetransfer.IncomingFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.openStreams(HttpClientRetrieveFileTransfer.java:658) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:885) at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576) at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:389) at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.read(FileReader.java:240) at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:172) ... 12 more
Eclipse Luna (4.4) with Oracle Java EE Tools Oracle Enterprise Pack for Eclipse 12.1.3.1.1 WinXp (32 bits) Ironport Proxy (no authentication) With initial distribution, no access to Marketplaces (even M2E Connector Marketplace). Removing following three files from plugins folder as suggested above fixed the problem. org.eclipse.ecf.provider.filetransfer.httpclient4.ssl_1.0.0.v20140528-1625.jar org.eclipse.ecf.provider.filetransfer.httpclient4_1.0.500.v20140528-1625.jar org.eclipse.ecf.provider.filetransfer.ssl_1.0.0.v20140528-1625.jar Since this solution was not recommended, I installed the following fix: http://download.eclipse.org/rt/ecf/httpclient4/org.eclipse.ecf.provider.httpclient4_3.9.0.zip After this installation, I was also able to access Eclipse the Marketplaces. Fix appears to be good.
(In reply to Laurent Gauthier from comment #78) > Fix appears to be good. Keep in mind, the "fix" MIGHT put your workbench in a state that "automatic update" won't work during the next release ... and MIGHT make it incompatible with other plugins that use different versions of httpclient. That's why we are hesitant to call it a "fix" ... but as a work-around, glad it got you going. Keep in mind, too, that with Luna, there was a bug in "Market Place Client" and it was said to get it working people update to their latest version in http://download.eclipse.org/mpc/luna (And, sorry, I could not find bug report or original note in the 5 minutes I tried ... but, it's probably there in bugzilla somewhere around last June I'm assuming it will be included in SR1 (due out near end of September) ... at least that will take one variable out of the equation. IronPort proxy. That's interesting. Does it use the NTLMv2 protocol others have mentioned? The web seems to mention WCCP protocol. (what ever that is). And Windows XP, eh? Like living on the edge? (just kidding ... being silly).
(In reply to Scott Lewis from comment #58) Setting "-Djava.net.preferIPv4Stack=true" after "-vmargs" in "eclipse.ini" - Seams to give me a full functioning Eclipse EE Luna regarding to Eclipse updates and Marketplace. This might be a totally different scenario, not related to the core of this problem. But this might help as a temporary work-around for some users
(In reply to Magnus Skoglund from comment #80) > (In reply to Scott Lewis from comment #58) > > Setting "-Djava.net.preferIPv4Stack=true" after "-vmargs" in "eclipse.ini" - > Seams to give me a full functioning Eclipse EE Luna regarding to Eclipse > updates and Marketplace. This might be a totally different scenario, not > related to the core of this problem. But this might help as a temporary > work-around for some users Could you please give a few details about your environment? e.g. are you on an NTLMv2-proxied network? Some other proxy? Thanks for the info. It would be very helpful if others that are experiencing this problem specifically on NTLMv2 proxied networks could verify whether this work-around also works for them.
(In reply to Magnus Skoglund from comment #80) > (In reply to Scott Lewis from comment #58) > > Setting "-Djava.net.preferIPv4Stack=true" after "-vmargs" in "eclipse.ini" - Works for me, too.
(In reply to Magnus Skoglund from comment #80) > (In reply to Scott Lewis from comment #58) > > Setting "-Djava.net.preferIPv4Stack=true" after "-vmargs" in "eclipse.ini" - > Seams to give me a full functioning Eclipse EE Luna regarding to Eclipse > updates and Marketplace. This might be a totally different scenario, not > related to the core of this problem. But this might help as a temporary > work-around for some users It's work!
(In reply to Hilton Wichwski Silva from comment #83) > (In reply to Magnus Skoglund from comment #80) > > (In reply to Scott Lewis from comment #58) > > > > Setting "-Djava.net.preferIPv4Stack=true" after "-vmargs" in "eclipse.ini" - > > Seams to give me a full functioning Eclipse EE Luna regarding to Eclipse > > updates and Marketplace. This might be a totally different scenario, not > > related to the core of this problem. But this might help as a temporary > > work-around for some users > > It's work! I'm very glad to hear that this work-around is working for some people, but before we conclude this 'fixes things' we need to try to understand better what's going on. First, based upon previous reports, it seems that it's NTLMv2 proxy authentication that is (mostly) showing this problem. And, it seems that it's version 4.2.x of Apache httpclient that shows the problem (in Juno), and that 4.1.X of httpclient (luna) and comment 58 It would be very helpful if someone that's experiencing this problem could verify (or clarify) their proxy details...i.e. using NTLMv2 proxying, and Luna instance of Eclipse. Then, please apply this work-around and report whether it fixes the problem. Perhaps this is what Magnus and Hilton have already done, and if so please just verify that this is your environment (e.g. NTLMv2, Luna, Java 1.7, etc). Since there are so many variables at play with this issue it would be useful to be very explicit about the environments. Thanks.
I can't confirm if my proxy use NTLMv2 I using Eclipse Luna Jvm: jrockit6 On real machine with Windows 7
Hi Stephan, when I remove those files I able to access the update servers. However JBoss disappears from "New Server Runtime Environment" and the existing one is marked as "Unbound". How are the two things related? (In reply to Stephan Undisclosed from comment #29) > I have removed : > > org.eclipse.ecf.provider.filetransfer.httpclient4.ssl_1.0.0.v20140528-1625. > jar > org.eclipse.ecf.provider.filetransfer.httpclient4_1.0.500.v20140528-1625.jar > org.eclipse.ecf.provider.filetransfer.ssl_1.0.0.v20140528-1625.jar > > and everything appears to work fine; no more exceptions of the sort "Proxy > access denied" appear :)
Working on Windows 7 x 64, LDAP. <a href="show_bug.cgi?id=422665#c80">comment #80</a> worked for me. Additionally i had to change settings to manual, enter proxy (no auth info), then back to native. Version: Luna Release (4.4.0) Build id: 20140612-0600
~~~~~~~~~~~~~~~~~~ NTLM auth (not v2) ~~~~~~~~~~~~~~~~~~ The solution: -Djava.net.preferIPv4Stack=true doesn't work. The solution: -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4 makes 'Eclipse Update' working. Plugin like 'Code Recommenders' doesn't work.
(In reply to Fabio Borlenghi from comment #88) > The solution: > -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf. > provider.filetransfer.httpclient4 > > makes 'Eclipse Update' working. > Plugin like 'Code Recommenders' doesn't work. For the record: Code Recommenders doesn't use ECF, so that the property has no effect on it is not surprising. Instead of ECF, Code Recommenders uses Eclipse Aether whose org.eclipse.aether.transport.http plugin uses Apache httpclient 4.2.x internally. Maybe it's time for an ECF-based Aether transport plugin...
(In reply to Andreas Sewe from comment #89) > (In reply to Fabio Borlenghi from comment #88) > > The solution: > > -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf. > > provider.filetransfer.httpclient4 > > > > makes 'Eclipse Update' working. > > Plugin like 'Code Recommenders' doesn't work. > > For the record: Code Recommenders doesn't use ECF, so that the property has > no effect on it is not surprising. Instead of ECF, Code Recommenders uses > Eclipse Aether whose org.eclipse.aether.transport.http plugin uses Apache > httpclient 4.2.x internally. > > Maybe it's time for an ECF-based Aether transport plugin... If not obvious, please open a separate bug for code-recommender, since doesn't appear related to this one.
For those of you having "proxy trouble" with 4.4 (Luna), I have a favor to ask ... for those of you willing to help us test things, since we do not really have appropriate environments. 1. We have just produced an I-build in 4.5 (Mars) stream, that has an updated httpcomponents from Apache, the 4.3 stream, instead of the 4.2 stream, as in Luna (or, Eclipse 4.4) release. http://download.eclipse.org/eclipse/downloads/drops4/I20140923-0800/ While we have no concrete reason to think this will solve anything ... I think it'd be worth trying, so see if there is any change in behavior. The downloads there are "plain" Eclipse, no "market place", or similar. If you don't know what to repo to go to, or what to install, I suggest can go to the 4.5-I-build repository (.../eclipse/updates/4.5-I-build/) an try to install "releng tools" and anything else not already installed. (And, remember, don't use for your production environment, or your "real" code workspace ... this is meant to be pure and simple test of just the Eclipse SDK and p2.) Second request, in next comment, with attachment ...
Created attachment 247312 [details] ant file to use p2 director to install Especially if you have an obvious problem, getting update to work, with "plain Eclipse SDK", with your proxies, it has occurred to me there *might* be some interaction with the "UI" part of the code. For example, -- a random guess -- perhaps the UI is "messing up" your settings or ignore them, or something. So, I've attached a simple ant script that will download an version of Eclipse, unzip it, and try to use "p2 director" to install a new feature from a site on our eclipse build machine. It has just occurred to me, if you normally have to set "network proxy settings" in the UI, you might need to modify the script to copy your proxy settings into the freshly unzipped version. They are kept in a file named "org.eclipse.core.net.prefs". Of course, there's 101 variations on this theme, I'm just suggesting this script as a starting point, to experiment with "headless" use. You can run it from the command line (assuming ant and java defined on your path) or you could probably even run it from Eclipse, and "simulate" headless mode ... though even then, not still sure it will "pick up" your normal "core.net.prefs". One more suggestion ... in next comment ...
As my last suggestion for today, I'll call your attention to bug 441733. I've asked the Eclipse Foundation if they can set up a "test environment" where various "known-problem-proxies" could be set up that would help us both in debugging and on going tests. While this would not actually be implemented for a while, if at all, now is the time to make the request, and tell them what we need. But, as you can gather, neither Scott nor I know what to tell them, exactly ... we'd be three quarters guessing ... and, from the comments many of you have left here, I am not sure any of you could "speak IT" well enough to give the data to set up an environment to reproduce the problem (and, forgive me if I'm wrong, or just missed it). But, my idea was that perhaps you could request your "IT departments" to comment on that bug, with "technical specifications". And/or, they might start with exchanging email with 'webmaster@eclipse.org", and mention their willingness help with bug 441733. I partially say this, since in my experience, they may not want to "make public" the details of their setup by writing them in bugzilla where they'd remain forever viewable by anyone. But, they might be willing to have a few phone calls, or exchange a few emails with our webmaster? So, those three are my suggestions for now. I realize some of you won't be able to help, either because your busy with your normal jobs, or simply don't know how to do what I suggest ... and that's fine ... no prejudice ... but, it was the best I could think off, in the absence of having our own "proxy specialist team". Thanks,
(In reply to David Williams from comment #91) > For those of you having "proxy trouble" with 4.4 (Luna), I have a favor to > ask ... for those of you willing to help us test things, since we do not > really have appropriate environments. > > [...] > > While we have no concrete reason to think this will solve anything ... I > think it'd be worth trying, so see if there is any change in behavior. I still get "Proxy Authentication Required" when trying to access any software site with your 4.5 build. I'm not sure if there is any change from Luna, since I don't use it because of this bug and it has been a while since I tested Luna. I don't even need to try to install anything, as contacting any software site fails (tested with several existing ones). After closing the error dialog, the "Install New Sowftware" dialog just says "Could not find <repo>" when selecting a repo from the drop-down. Exception: org.eclipse.ecf.filetransfer.BrowseFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:287) at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Maybe I should mention that our setup involves a trusted KeyStore we put in the eclipse root directory and set in eclipse.ini (works in Kepler) like this (after -vmargs): -Djavax.net.ssl.trustStore=truststore.jks -Djavax.net.ssl.trustStorePassword=*** -Djavax.net.ssl.keyStore=truststore.jks -Djavax.net.ssl.keyStorePassword=*** -Dhttps.proxyHost=<proxyhost> -Dhttps.proxyPort=3128
(In reply to Konstantin Mayr from comment #94) > (In reply to David Williams from comment #91) > > For those of you having "proxy trouble" with 4.4 (Luna), I have a favor to > > ask ... for those of you willing to help us test things, since we do not > > really have appropriate environments. > > > > [...] > > > > While we have no concrete reason to think this will solve anything ... I > > think it'd be worth trying, so see if there is any change in behavior. > > I still get "Proxy Authentication Required" when trying to access any > software site with your 4.5 build. I'm not sure if there is any change from > Luna, since I don't use it because of this bug and it has been a while since > I tested Luna. I don't even need to try to install anything, as contacting > any software site fails (tested with several existing ones). After closing > the error dialog, the "Install New Sowftware" dialog just says "Could not > find <repo>" when selecting a repo from the drop-down. > > Exception: > org.eclipse.ecf.filetransfer.BrowseFileTransferException: Proxy > Authentication Required > at > org.eclipse.ecf.provider.filetransfer.httpclient4. > HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:287) > at > org.eclipse.ecf.provider.filetransfer.browse. > AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) > > > > Maybe I should mention that our setup involves a trusted KeyStore we put in > the eclipse root directory and set in eclipse.ini (works in Kepler) like > this (after -vmargs): > -Djavax.net.ssl.trustStore=truststore.jks > -Djavax.net.ssl.trustStorePassword=*** > -Djavax.net.ssl.keyStore=truststore.jks > -Djavax.net.ssl.keyStorePassword=*** > -Dhttps.proxyHost=<proxyhost> > -Dhttps.proxyPort=3128 Thanks for checking. Not sure if your "key store" case is a "central" to the issue, or "yet another variation". But appreciate you trying out the new version and providing the extra info.
(In reply to David Williams from comment #90) > (In reply to Andreas Sewe from comment #89) >> (In reply to Fabio Borlenghi from comment #88) >>> Plugin like 'Code Recommenders' doesn't work. >> >> For the record: Code Recommenders doesn't use ECF, so that the property has >> no effect on it is not surprising. Instead of ECF, Code Recommenders uses >> Eclipse Aether whose org.eclipse.aether.transport.http plugin uses Apache >> httpclient 4.2.x internally. > > If not obvious, please open a separate bug for code-recommender, since > doesn't appear related to this one. For the record, this is Bug 430017.
Created attachment 247560 [details] ECF versions in latest Luna update
I also meant to say that the ECF in question broke the fix from comment 58 for me.
(In reply to andrei@lenkei.com Andrei Lenkei from comment #98) > I also meant to say that the ECF in question broke the fix from comment 58 > for me. Luna SR1 does not/cannot include the fix from comment 58, since including this fix in SR1 would mean returning to apache httpclient 4.1, and thereby breaking other Eclipse plugins that depend upon httpclient 4.2. If there is sufficient desire, I will offer to post another fix (like comment 58) that can be used with Luna SR1. Just so it's clear to everyone: like the fix in comment 58 it will simply return to using apache httpclient 4.1, and this will mean that it may result in other regressions e.g. see comment 75. One other thing to clarify in case it's not already clear: The ECF codebase itself hasn't changed at all since Kepler. The only thing that is changing with comment 58 fix and Luna SR1 is the version of apache httpclient being used: Kepler - httpclient 4.1 Luna - httpclient 4.2 comment 58 - httpclient 4.1 Luna SR1 - httpclient 4.2 Mars M2 - httpclient 4.3 see comment 91 and that's why upgrading to Luna SR1 is resulting in this problem reappearing for those of you experiencing the problem. Please respond on this bug if the people experiencing this problem would like another workaround/fix, analogous to comment 58 but targeted for Luna SR1.
A more permanent solution that doesn't break other plugins is very much desired. I am now forced to return to Kepler in the meanwhile.
Just to cross-reference, see bug 446110 as a possibly related issue or use-case.
I may be able to do some troubleshooting (although I've forgotten how to do the side-by-side installs to enable 4.5pre-release testing). 90% of my time is behind an authenticated proxy service, which on 4.4/apachecomponents 4.2 gives me the same issues. [luckily I also have access to networks that are non-authenticated, so performing updates per se is possible (but fiddly)] In addition, I am able to run a local proxy (fiddler) which allows me to trace some aspects of the problem. It appears that the authentication header is being missed from all the requests being sent, regardless of the actual authentication settings within the Eclipse UI. The response from the proxy is: Proxy-Authenticate Header is present: NTLM Proxy-Authenticate Header is present: Basic realm="Internet via someproxy" No WWW-Authenticate Header is present. This is true for both native (system) settings (which were ok under 4.2) and where authentication is explicitly set in the network connections. It would appear that under explicit authentication it will be Eclipse' responsibility to pass in the credentials, whereas with native it will be down to the component to discover them. This does point to an apache-component related bug [not sending credentials, either discovered or supplied]. If so then can this can be checked with the apache project, since if the analysis is correct it should be a general problem with version 4.2? Software updates do work if I request that Fiddler performs authentication on behalf of the caller.
I had the same "proxy authentication required" error in my Eclipse Luna installation (I'm behind a proxy too). I worked around it by overwriting existing org.apache.httpcomponent bundles in my plugins directory with brand new ones downloaded directly from the httpcomponents project page: org.apache.httpcomponents.httpclient_4.3.5.jar org.apache.httpcomponents.httpcore_4.3.2.jar I then proceeded to restart eclipse with the -clean option (in the eclipse.ini) and the "check for updates" action completed successfully.
(In reply to simon coleman from comment #102) First, thanks for doing this Simon. It's very helpful. > I may be able to do some troubleshooting (although I've forgotten how to do > the side-by-side installs to enable 4.5pre-release testing). > > 90% of my time is behind an authenticated proxy service, which on > 4.4/apachecomponents 4.2 gives me the same issues. To understand what you are saying: you are using apache 4.4 in some other program (not eclipse), and it's showing the same problems as Eclipse/4.2 for your authenticated proxy service? > [luckily I also have access to networks that are non-authenticated, so > performing updates per se is possible (but fiddly)] > > In addition, I am able to run a local proxy (fiddler) which allows me to > trace some aspects of the problem. > > It appears that the authentication header is being missed from all the > requests being sent, regardless of the actual authentication settings within > the Eclipse UI. > > The response from the proxy is: > Proxy-Authenticate Header is present: NTLM > Proxy-Authenticate Header is present: Basic realm="Internet via someproxy" > No WWW-Authenticate Header is present. Ok. Thanks for this info. > > This is true for both native (system) settings (which were ok under 4.2) and > where authentication is explicitly set in the network connections. > It would appear that under explicit authentication it will be Eclipse' > responsibility to pass in the credentials, whereas with native it will be > down to the component to discover them. > > This does point to an apache-component related bug [not sending credentials, > either discovered or supplied]. If so then can this can be checked with the > apache project, since if the analysis is correct it should be a general > problem with version 4.2? It could be communicated to the the apache httpclient project, but I'm not closely connected with that project myself. Before doing more in that regard, are there any httpcomponents committers that are on this bug currently that could interact with the project more easily/more directly on this issue? > > Software updates do work if I request that Fiddler performs authentication > on behalf of the caller. Thanks again for the information. One other question: If I/we make changes to ECF filetransfer code...e.g. to workaround the httpclient problem by using some other filetransfer provider in affected environments...would you be willing/able to help test such workarounds in your environment?
(In reply to Gabriele Catania from comment #103) Hi Gabriele, First thanks for this information. > I had the same "proxy authentication required" error in my Eclipse Luna > installation (I'm behind a proxy too). > > I worked around it by overwriting existing org.apache.httpcomponent bundles > in my plugins directory with brand new ones downloaded directly from the > httpcomponents project page: > > org.apache.httpcomponents.httpclient_4.3.5.jar > org.apache.httpcomponents.httpcore_4.3.2.jar Could you please provide the full URL for these jars? I'm not sure whether the httpclient project creates jars that are also OSGi bundles, and I would like to examine them. > > I then proceeded to restart eclipse with the -clean option (in the > eclipse.ini) and the "check for updates" action completed successfully. Although I will verify this if you let me know what the full URL for these jars is, I believe what may be happening when you do this is this: 1) When you replace the Orbit-created jars with the jars above, they are no longer proper OSGi bundles 2) Since they are not proper bundles, the ECF httpclient4 provider cannot start/initialize/be used at runtime. 3) ECF has a multi-provider architecture, and since the httpclient4 provider cannot be used, it falls back on/uses the JRE-exposed provider (uses httpconnection), and this works. This is what I suspect is happening. OTOH if the httpclient-produced jars are actually well formed OSGI bundles (and I will verify this if you let me know which URL you used to retrieve these), then this would point to some problem in the Orbit-created versions of these httpclient bundles. Again, thanks for your help.
(In reply to Scott Lewis from comment #105) > Again, thanks for your help. I had the same questions as Scott (and still do) but, did notice the 4.3.5 client is new, even from a month or two back when we put 4.3.4 in Orbit. Looking that the release notes, for 4.3.5, it only lists to bugs fixed, one very specific, the other less so: = = = = = Changelog: ------------------- * Improved SSL cert subject parsing * [HTTPCLIENT-1524] RFC 2617 auth schemes (basic and digest) cannot handle auth parameters with mixed or upper case = = = = = So, my point is, to my naive eyes that latter one seems like could definitely be related to this bug? Enough so, I think I'll start the process to include it, but ... would still like to here those answers. Perhaps Gabriele made is own OSGi bundles?
(In reply to David Williams from comment #106) <stuff deleted> > * [HTTPCLIENT-1524] RFC 2617 auth schemes (basic and digest) cannot handle > auth parameters with mixed or upper case > > = = = = = > > So, my point is, to my naive eyes that latter one seems like could > definitely be related to this bug? RFC 2617 is regarding http authentication rather than NTLM auth, so although it's still possible the fix is related to this bug...I'm a little doubtful it will solve things...especially given info in comment 102.
(In reply to Scott Lewis from comment #107) > RFC 2617 is regarding http authentication rather than NTLM auth, so although > it's still possible the fix is related to this bug...I'm a little doubtful > it will solve things...especially given info in comment 102. You may find the OSGi-Bundles on the Download-Site for httpcomponents (they are marked with "OSGi bundle"): http://hc.apache.org/downloads.cgi Specifically I used: http://mirrors.ae-online.de/apache//httpcomponents/httpclient/binary/httpcomponents-client-4.3.5-osgi-bin.zip http://mirrors.ae-online.de/apache//httpcomponents/httpcore/binary/httpcomponents-core-4.3.2-osgi-bin.zip But replacing those on the MARS-Test-Eclipse that was posted earlier on this thread, did NOT help me behind our NTLMv2 Proxy. I still couldn't access software sites with "Proxy Authentication Required". I verified that httpcompnents is at 4.3.5 with the Installation Details -> Plugins window. I still may have something misconfigured of course (I still have "-Dhttps.proxyHost" and "-Dhttps.proxyPort" in eclispe.ini for example).
I was able to work around this issue by copying the Eclipse 4.3 plugins to 4.4 org.apache.httpcomponents.httpclient_4.1.3.v201209201135.jar org.apache.httpcomponents.httpcore_4.1.4.v201203221030.jar It works through the proxy issues and I was able to install packages I needed. I am not sure what the downgrade may do to other functionality.
(In reply to Scott Lewis from comment #105) Hi Scott, apache httpcomponents actually also provides OSGI bundle versions for their artifacts, which you will find in the httpcomponents download page here: https://hc.apache.org/downloads.cgi for the record, these are the download links that show up for me now: http://ftp.nluug.nl/internet/apache//httpcomponents/httpclient/binary/httpcomponents-client-4.3.5-osgi-bin.zip http://ftp.nluug.nl/internet/apache//httpcomponents/httpcore/binary/httpcomponents-core-4.3.2-osgi-bin.zip please note that you will have to unpack the zip files to get the jars inside.
(In reply to Konstantin Mayr from comment #108) > (I still have > "-Dhttps.proxyHost" and "-Dhttps.proxyPort" in eclispe.ini for example). I do not have those settings in my .ini file. I will try to investigate tomorrow if I can understand wich provider is being used by my eclipse, and if it's falling back to the jvm stack as suggested by Scott.
I also have problems with updates with WireframeSketcher (which is an RCP app) when behind an NTLM proxy. I also have another component that requires HTTP access and it had the same issue. It was based on httpclient too but now I have migrated it to HttpURLConnection and it works properly behind the proxy. Is there some property to force ECF to use HttpURLConnection too?
(In reply to Peter Severin from comment #112) > I also have problems with updates with WireframeSketcher (which is an RCP > app) when behind an NTLM proxy. I also have another component that requires > HTTP access and it had the same issue. It was based on httpclient too but > now I have migrated it to HttpURLConnection and it works properly behind the > proxy. > > Is there some property to force ECF to use HttpURLConnection too? Yes, see the property documented here: https://wiki.eclipse.org/Disabling_Apache_Httpclient Note that it's now the org.eclipse.ecf.provider.filetransfer.httpclient4 provider that uses 4.x of Apache HttpClient. With the httpclient4 provider disabled, ECF will use the JRE-provided HttpURLConnection.
(In reply to Scott Lewis from comment #104) > (In reply to simon coleman from comment #102) > > First, thanks for doing this Simon. It's very helpful. > > > I may be able to do some troubleshooting (although I've forgotten how to do > > the side-by-side installs to enable 4.5pre-release testing). > > > > 90% of my time is behind an authenticated proxy service, which on > > 4.4/apachecomponents 4.2 gives me the same issues. > > To understand what you are saying: you are using apache 4.4 in some other > program (not eclipse), and it's showing the same problems as Eclipse/4.2 for > your authenticated proxy service? > Sorry - that was rather ambiguous. I'm only using eclipse 4.4SR1 at present, but it seemed the next thing was to start trying some different apachecomponent versions & I wanted to confirm the version in use was the default install of apachecomponents, which seems to have a version number of 4.2 > > [luckily I also have access to networks that are non-authenticated, so > > performing updates per se is possible (but fiddly)] > > > > In addition, I am able to run a local proxy (fiddler) which allows me to > > trace some aspects of the problem. > > > > It appears that the authentication header is being missed from all the > > requests being sent, regardless of the actual authentication settings within > > the Eclipse UI. > > > > The response from the proxy is: > > Proxy-Authenticate Header is present: NTLM > > Proxy-Authenticate Header is present: Basic realm="Internet via someproxy" > > No WWW-Authenticate Header is present. > > Ok. Thanks for this info. > > > > > This is true for both native (system) settings (which were ok under 4.2) and > > where authentication is explicitly set in the network connections. > > It would appear that under explicit authentication it will be Eclipse' > > responsibility to pass in the credentials, whereas with native it will be > > down to the component to discover them. > > > > This does point to an apache-component related bug [not sending credentials, > > either discovered or supplied]. If so then can this can be checked with the > > apache project, since if the analysis is correct it should be a general > > problem with version 4.2? > > It could be communicated to the the apache httpclient project, but I'm not > closely connected with that project myself. Before doing more in that > regard, are there any httpcomponents committers that are on this bug > currently that could interact with the project more easily/more directly on > this issue? > > > > > Software updates do work if I request that Fiddler performs authentication > > on behalf of the caller. > > Thanks again for the information. > > One other question: If I/we make changes to ECF filetransfer code...e.g. to > workaround the httpclient problem by using some other filetransfer provider > in affected environments...would you be willing/able to help test such > workarounds in your environment? Absolutely [I'm just about to go trawling through the remainder of the replies to see if there's anything I ought to try out just now, eg, swapping the apache http components...]
I'm not using a proxy and still encounter a "Cannot install remote marketplace locations" problem. I mention this first as it seems everyone else is using a proxy and having the problem. Marketplace via Luna was working fine for me today (setting up a new installation) until I applied the Eclipse-specific updates. About now says: Version: Luna Service Release 1 (4.4.1) Build id: 20140925-1800 Now when I run Eclipse Marketplace, this error occurs: Cannot install remote marketplace locations: Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: Stream closed org.eclipse.core.runtime.CoreException: Cannot complete request to http://marketplace.eclipse.org/catalogs/api/p: Stream closed at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:148) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:93) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80) at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:43) at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$5.run(MarketplaceWizardCommand.java:276) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122) Caused by: java.io.IOException: Stream closed at java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:151) at java.io.BufferedInputStream.read1(BufferedInputStream.java:273) at java.io.BufferedInputStream.read(BufferedInputStream.java:334) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) at java.io.InputStreamReader.read(InputStreamReader.java:184) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(XMLEntityScanner.java:1753) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.arrangeCapacity(XMLEntityScanner.java:1629) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipString(XMLEntityScanner.java:1667) at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:196) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:812) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:777) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:648) at org.eclipse.epp.internal.mpc.core.service.MarketplaceUnmarshaller.unmarshal(MarketplaceUnmarshaller.java:54) at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:132) ... 5 more I did a fresh Eclipse Java EE install and only applied the Eclipse updates (installed no other plugins) and reproduced the problem. The funny thing is if I reboot, Eclipse Marketplace works for one install. Then not again until I reboot. That's a puzzler.... so what Eclipse or Windows "thing" is tripped to prevent it? I tried the easy workarounds: 1. -Djava.net.preferIPv4Stack=true 2. -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4 but nether resolved that problem. What is the latest workaround or fix suggestions? Anything more I should try?
(In reply to Jeff Jensen from comment #115) > I'm not using a proxy and still encounter a "Cannot install remote > marketplace locations" problem. I mention this first as it seems everyone > else is using a proxy and having the problem. > > Marketplace via Luna was working fine for me today (setting up a new > installation) until I applied the Eclipse-specific updates. About now says: > Version: Luna Service Release 1 (4.4.1) > Build id: 20140925-1800 > > Now when I run Eclipse Marketplace, this error occurs: > Cannot install remote marketplace locations: Cannot complete request to > http://marketplace.eclipse.org/catalogs/api/p: Stream closed > > org.eclipse.core.runtime.CoreException: Cannot complete request to > http://marketplace.eclipse.org/catalogs/api/p: Stream closed > at > org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService. > processRequest(RemoteMarketplaceService.java:148) > at > org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService. > processRequest(RemoteMarketplaceService.java:93) > at > org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService. > processRequest(RemoteMarketplaceService.java:80) > at > org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService. > listCatalogs(DefaultCatalogService.java:43) > at > org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$5. > run(MarketplaceWizardCommand.java:276) > at > org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext. > java:122) > Caused by: java.io.IOException: Stream closed > at java.io.BufferedInputStream.getInIfOpen(BufferedInputStream.java:151) > at java.io.BufferedInputStream.read1(BufferedInputStream.java:273) > at java.io.BufferedInputStream.read(BufferedInputStream.java:334) > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) > at java.io.InputStreamReader.read(InputStreamReader.java:184) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityScanner. > load(XMLEntityScanner.java:1753) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityScanner. > arrangeCapacity(XMLEntityScanner.java:1629) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityScanner. > skipString(XMLEntityScanner.java:1667) > at > com.sun.org.apache.xerces.internal.impl.XMLVersionDetector. > determineDocVersion(XMLVersionDetector.java:196) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration. > parse(XML11Configuration.java:812) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration. > parse(XML11Configuration.java:777) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java: > 141) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser. > parse(AbstractSAXParser.java:1213) > at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser. > parse(SAXParserImpl.java:648) > at > org.eclipse.epp.internal.mpc.core.service.MarketplaceUnmarshaller. > unmarshal(MarketplaceUnmarshaller.java:54) > at > org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService. > processRequest(RemoteMarketplaceService.java:132) > ... 5 more This doesn't appear to me to be the same issue as this bug. Based upon the stack trace above (which doesn't obviously refer to either ECF filetransfer or Apache httpclient code) I would suggest opening a new bug with the EPP project https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EPP for diagnosis.
(In reply to Scott Lewis from comment #116) > This doesn't appear to me to be the same issue as this bug. > > Based upon the stack trace above (which doesn't obviously refer to either > ECF filetransfer or Apache httpclient code) I would suggest opening a new > bug with the EPP project > https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EPP for diagnosis. Thank you Scott. For any future reference, it is bug 451121.
For the daring among you, there is a build of Eclipse SDK that has org.apache.httpcomponents.client 4.3.6.x, and org.apache.httpcomponents.core 4.3.3.x http://download.eclipse.org/eclipse/downloads/drops4/M20141203-0800/ There is some indication this might help some cases of proxy access, but, we doubt it will fix them all. So, if you get a chance, and can test M20141203-0800 to see if it "goes through" your proxy correctly, that would be interesting, and helpful to know your observations. But, beware ... this is not to use or replace your current "production environment" (It has not been extensively tested) AND probably should not even open your "production workspace", just in case. But if anyone can download a version, and try to use p2 to install something, it would be helpful to know if your experience or test doing so is better (or worse!?) than with a plain, out of the box, "4.4.1". NOTE: you have to use the SDK, by downloading it, the "p2 repository" for that build is not quite right, and does not have the new httpcomponents. If you report "it works" or "does not work" please also state (even if repeating) as much about your proxy as you know. And, I just tried it once, to make sure the normal case worked (it did) and it seemed a lot faster to me ... though, that is not a very good sample size. :)
I've tried new build, my results with "MS NTLMv2 Proxy": 1. After startup with clean workspace in "Network Connections" "Active Provider -> Native" is selected. "Help -> Check for Updates" does not work, error "Some sites could not be found. See the error log for more detail. HTTP Proxy Authentication Required:". Does it mean automatic proxy server detection does not work? It works in Firefox, Cubby etc. May be my expectation is different... 2. Changed "Active Provider -> Manual" and entered Host, Port, User and Password for HTTP. "Help -> Check for Updates" does work! 3. Switched to production Eclipse 4.4.1. Tried "Help -> Check for Updates" and "Eclipse Marketplace" --> IT WORKS! But looks strange for me, there must be some caching in JVM or Proxy-Server, because it did not worked before with 4.4.1 I will try reproduce 3. after reboot...
Tried Eclise 20141203 with org.apache.httpcomponents.httpclient_4.3.6.v201411290715.jar org.apache.httpcomponents.httpcore_4.3.3.v201411290715.jar but it doesn't work with proxy Last working is Eclipse 4.3.2 with org.apache.httpcomponents.httpcore_4.1.4.v201203221030.jar org.apache.httpcomponents.httpclient_4.1.3.v201209201135.jar Workaround is to replace new version of jars by older.
What's the status in here? Any plans to have it fixed? Thanks.
(In reply to Maciej Hanak from comment #121) > What's the status in here? Any plans to have it fixed? > Thanks. The status is we would *like* to fix for Mars, but since we have no dedicated experts in "proxies" (nor, not even the hardware/network setups to test), we'd need some sound analysis and proposed patches from community to fix. Sorry I don't have more encouraging news.
@David, You should be behind the proxy at IBM, don't you? Anyway I will take a look. It seems proxy was working fine in previous releases and got broken in Luna right? Do you know more about the issue? It would be nice to pinpoint the root cause easier.
(In reply to Maciej Hanak from comment #123) > @David, > > You should be behind the proxy at IBM, don't you? > Anyway I will take a look. > > It seems proxy was working fine in previous releases and got broken in Luna > right? Yes, that's right. Here's my summary: The handling of NTLMv2 proxies in Eclipse and the Marketplace client (same p2+ECF codebase) was working up until approximately Luna M5. The breakage occurred apparently from ECF upgrading from Apache Httpclient 4.1.x to using 4.2.x as requested via bug 423296. See comments on bug 423296 for details, but the technical summary of this breakage is that Apache Httpclient 4.2.x changed the way it handled NTLMv2 proxies relative to Apache 4.1.x and so resulted in this problem for people with certain proxied networks (suspected by me to be NTLMv2-proxied networks specifically). Also see comment 58 on this bug. What I did via comment 58 was make available a 'downshift' version of ECF filetransfer that used Httpclient 4.1.x, and this downshift version resulted in people experiencing this problem being able to use proxied networks with Eclipse. The apparent success of the downshift has convinced me that this problem was introduced via the upgrade of Httpclient from 4.1.x->4.2.x. Since this discovery, David Williams and I have been trying more recent versions (i.e. 4.3.x) of Httpclient in the hopes that newer version of Httpclient will fix this issue. Unfortunately, so far have been reporting that 4.2+ versions of HttpClient have not fixed their proxy problem. I/ECF do not have the means/resources to even reproduce this problem myself, since we don't have a NTLMv2 proxy network available to us, nor the resources to simulate such an environment. > Do you know more about the issue? Yes. If you would like to discuss/meet in some other forum let me know and we can chat. > It would be nice to pinpoint the root cause easier. I am completely convinced that the cause is the use of Httpclient 4.2+ rather than Httpclient 4.1. I know for sure, for example, that nothing substantive about ECF filetransfer was even changed since the Httpclient 4.2 changeover in bug 423296, so this cannot be a regression introduced by changes to ECF code.
(In reply to Scott Lewis from comment #124) <stuff deleted> > occurred apparently from ECF upgrading from Apache Httpclient 4.1.x to using > 4.2.x as requested via bug 423296. Sorry. I meant bug 423196.
(In reply to Maciej Hanak from comment #123) > @David, > > You should be behind the proxy at IBM, don't you? Yes and works flawlessly. But ... that simply complicates things, since it means it "works for some proxies, configured in some way", but not for others. Hard for any one person or group to cover all the bases in the complex proxy world. (In reply to Scott Lewis from comment #124) > I am completely convinced that the cause is the use of Httpclient 4.2+ > rather than Httpclient 4.1. I know for sure, for example, that nothing > substantive about ECF filetransfer was even changed since the Httpclient 4.2 > changeover in bug 423296, so this cannot be a regression introduced by > changes to ECF code. You could be right. But, without knowing the exact cause, you could be subject to what I would call "the programmers fallacy": my code didn't change ... so, must be a problem with the other code that did change. In other words, without knowing more, I'd say it is just as likely that Httpclient 4.2+ fixed something, perhaps even plugged a security hole, and that previously ECF "worked by chance", with the bug, and now that the bug is fixed, ECF must change ... something. And it does not need to be anything as dramatic as a bug or security fix. Could be something incidental ... where the "order" of something changed, and the order was never part of the "contract", but ECF, by chance, assumed one order, and now getting in a different order, so ECF must react (say, by examining whole list before knowing what action to take). I am not saying that any of this *is* the case ... I am just saying it is a *possibility*, until we, someone, understands the cause of those cases that fail. (In reply to Maciej Hanak from comment #123) > Anyway I will take a look. Great! if you are lucky enough to have a "failing case", seems you could "run a second instance" of Eclipse, using the first to set a few break points, see if there's anything obvious that leads to the unnecessary prompt? Could still be a "full day chore", so not saying it is easy, but having a "failing case" sure makes it easier. Otherwise, it'd take "me" weeks of work, just to figure out how to make a failing case. And, IMHO, (I can't speak for Scott or ECF committers) it would be a valuable contribution, to not only suggest one fix, but to find a few key points in the flow to put "debug options", that could be "turned on" by an .options file, and give some improved tracing data. But, don't let me distract you from your main goal.
(In reply to David Williams from comment #126) <stuff deleted> > (In reply to Scott Lewis from comment #124) > > > I am completely convinced that the cause is the use of Httpclient 4.2+ > > rather than Httpclient 4.1. I know for sure, for example, that nothing > > substantive about ECF filetransfer was even changed since the Httpclient 4.2 > > changeover in bug 423296, so this cannot be a regression introduced by > > changes to ECF code. > > You could be right. But, without knowing the exact cause, you could be > subject to what I would call "the programmers fallacy": my code didn't > change ... so, must be a problem with the other code that did change. Of course this is possible, but lacking contrary or even more evidence what I described seems most likely to me. > > In other words, without knowing more, I'd say it is just as likely that > Httpclient 4.2+ fixed something, perhaps even plugged a security hole, and > that previously ECF "worked by chance", with the bug, and now that the bug > is fixed, ECF must change ... something. And it does not need to be anything > as dramatic as a bug or security fix. Could be something incidental ... > where the "order" of something changed, and the order was never part of the > "contract", but ECF, by chance, assumed one order, and now getting in a > different order, so ECF must react (say, by examining whole list before > knowing what action to take). Although of course you could be right, but as the author of much of the ECF filetransfer code, and having previously fought through the NTLMv2 proxy problems in Apache Httpclient (e.g. bug 252002 ), I disagree that your scenario is just as likely. But it's obviously still an open question. > > I am not saying that any of this *is* the case ... I am just saying it is a > *possibility*, until we, someone, understands the cause of those cases that > fail. Sure. Of course I welcome any further efforts to understand the cause better, and provide a fix, workaround, or whatever will improve the situation.
Guys, I'm behind NTLMv2 proyx and had to downgrade httpclient to be able to use Eclipse. It's annoying, I will spend some time on investigation and keep you posted.
I'm testing Eclipe 4.5M5 but still the same problem like in 4.4. I am also behind NTLMv2 proxy like Maciej.
(In reply to Scott Lewis from comment #127) > Although of course you could be right, but as the author of much of the ECF > filetransfer code, and having previously fought through the NTLMv2 proxy > problems in Apache Httpclient (e.g. bug 252002 ), I disagree that your > scenario is just as likely. But it's obviously still an open question. Yes, I didn't mean "just as likely" as being exactly 50/50. Just a possibility. And, I will say, I've been following the "httpcomponents mailing list" and I know a) they are *still* working on NTLMv2 and b) from the sounds of the discussion and bugs, I am surprised it ever worked, in Eclipse, for that particular proxy.
Just to note possibly related issue, even though I suspect *this* bug is more involved, I can't help noticing another "proxy issue" that related to "the exact format" of the URL: See bug 431902. Wanted to point that out, in case anyone notices in their debugging of failure cases that the URL of "their" repo, has "../" in them.
(In reply to David Williams from comment #130) > And, I will say, I've been following the "httpcomponents mailing list" and I > know a) they are *still* working on NTLMv2 and b) from the sounds of the > discussion and bugs, I am surprised it ever worked, in Eclipse, for that > particular proxy. So apparently one bug masked another one makes it even more complicated.
(In reply to David Williams from comment #130) > (In reply to Scott Lewis from comment #127) > > > Although of course you could be right, but as the author of much of the ECF > > filetransfer code, and having previously fought through the NTLMv2 proxy > > problems in Apache Httpclient (e.g. bug 252002 ), I disagree that your > > scenario is just as likely. But it's obviously still an open question. > > Yes, I didn't mean "just as likely" as being exactly 50/50. Just a > possibility. > > And, I will say, I've been following the "httpcomponents mailing list" and I > know a) they are *still* working on NTLMv2 and b) from the sounds of the > discussion and bugs, I am surprised it ever worked, in Eclipse, for that > particular proxy. FWIW: the reason it worked for NTLMv2 previously was that there is logic in the ECF httpclient provider to detect NTLMv2, fail and then use a different provider (e.g. the JRE-based one). My suspicion (confirmed to some degree by Stephen's investigation on bug I can't remember) was/is that the httpclient 4.2+ changes defeat/fool the NTLMv2 detector, meaning that the httpclient provider actually tries to continue on NTLMv2...and now fails because NTLMv2-via-httpclient doesn't work right or isn't configured right (at least for some configs). For those that have access to a proxy and are experiencing this bug: I would suggest concentrating on the httpclient4 provider located here: http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/providers/bundles/org.eclipse.ecf.provider.filetransfer.httpclient4 I would suggest trying to understand the runtime behavior of the NTLMProxyDetector class under 4.2+. My belief is that it's not working now as it did under httpclient 4.1: to detect httpclient, and then making the httpclient provider *fail*...thus triggering the fallback use of another provider on NTLM networks, which at least in Kepler worked fine. This is just a theory, of course, but a reasonable one given what's gone on WRT NTLMv2 and the ECF multi-provider architecture.
Hi, I did some small debuging exercise with my NTLMv2 proxy: https://bugs.eclipse.org/bugs/show_bug.cgi?id=440265#c16 " I've checked how httpclient in Luna works with my NTLMv2 proxy. Basically NTLMProxyDetector.isProxyType returns false since authScheme is null. AuthScheme authScheme = authState.getAuthScheme(); if (authScheme == null) return false; When isProxyType is invoked for the first time: scheme="NTLM" context is not null AuthState authState = (AuthState) context.getAttribute(ClientContext.PROXY_AUTH_STATE); authState is not null itself but within authState only state is not null, rest of properties auth* & credentials are null (I'm using Native proxy settings in eclipse) "
(In reply to Maciej Hanak from comment #134) Thanks. FYI ... you can just comment in this bug, not also bug 440265. Also, here you don't mention the difference between "first time" and "second time" of invoking it, as you did in bug 440265 comment 16 -- which seems like the important part of the the observation?
I commented in bug 440265 by mistake at 1st and then wanted to redirect. Sorry for confusion, will stick here from now on. Anyway isProxyType was invoked twice: 1st time with scheme="NTLM", 2nd time with scheme="UNCHALLENGED". I don't know why the content of authState is mostly null. All but state is null so we cannot even check scheme name to confirm we work with NTLM.
Workaround for anyone would like to use the newest Eclipse Luna behind NTLM proxy: According to following wiki page there is a possibility to disable apache httpclient and use JRE URLConnection-based provider instead https://wiki.eclipse.org/Disabling_Apache_Httpclient It seems working for me. Of course it's just a workaround and does not solve the core issue with httpclient. Guys: if you have any tips & ideas what can be checked/debugged or how NTLMProxyDetector should work - feel free to share ideas.
In Kepler and Luna, I had the same problems described here. I was able to workaround them (as noted elsewhere in this report via): -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient However, now that I upgraded to Mars, the workaround no longer works. Most update sites continue to function. However, I am not able to access any of the release repositories (e.g.): http://download.eclipse.org/releases/mars http://download.eclipse.org/releases/luna Other Eclipse update sites work fine (i.e.http://download.eclipse.org/eclipse/updates/4.5). I've tried the other workarounds and I couldn't get anything to work. I am behind a corporate proxy with a snooping SSL cert. I've tried both standalone releases of Mars and upgrading existing installations. Everything so far fails when trying to access the release update site. I'm wondering if that excludeContributers variable changed in Mars. Here is an example stack trace: !SUBENTRY 1 org.eclipse.equinox.p2.metadata.repository 4 1002 2015-06-26 07:31:55.106 !MESSAGE Unable to read repository at http://download.eclipse.org/releases/mars/. !STACK 1 org.eclipse.equinox.p2.core.ProvisionException: No repository found at http://download.eclipse.org/technology/epp/packages/mars/. at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.fail(AbstractRepositoryManager.java:395) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.oomph.util.ReflectUtil.invokeMethod(ReflectUtil.java:116) at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.fail(CachingRepositoryManager.java:300) at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:196) at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager$Metadata.loadRepository(CachingRepositoryManager.java:394) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) at org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository.addChild(CompositeMetadataRepository.java:166) at org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository.<init>(CompositeMetadataRepository.java:106) at org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepositoryFactory.load(CompositeMetadataRepositoryFactory.java:122) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57) at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768) at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.oomph.util.ReflectUtil.invokeMethod(ReflectUtil.java:116) at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:344) at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:146) at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager$Metadata.loadRepository(CachingRepositoryManager.java:394) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96) at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) at org.eclipse.equinox.p2.ui.ProvisioningUI.loadMetadataRepository(ProvisioningUI.java:440) at org.eclipse.equinox.internal.p2.ui.model.MetadataRepositoryElement.getMetadataRepository(MetadataRepositoryElement.java:126) at org.eclipse.equinox.internal.p2.ui.model.MetadataRepositoryElement.getRepository(MetadataRepositoryElement.java:115) at org.eclipse.equinox.internal.p2.ui.model.MetadataRepositoryElement.getQueryable(MetadataRepositoryElement.java:109) at org.eclipse.equinox.internal.p2.ui.QueryProvider.getQueryDescriptor(QueryProvider.java:88) at org.eclipse.equinox.internal.p2.ui.model.QueriedElement.fetchChildren(QueriedElement.java:101) at org.eclipse.equinox.internal.p2.ui.model.MetadataRepositoryElement.fetchChildren(MetadataRepositoryElement.java:77) at org.eclipse.equinox.internal.p2.ui.model.RemoteQueriedElement.fetchDeferredChildren(RemoteQueriedElement.java:34) at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:232) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) !SUBENTRY 2 org.eclipse.equinox.p2.metadata.repository 4 1000 2015-06-26 07:31:55.106 !MESSAGE No repository found at http://download.eclipse.org/technology/epp/packages/mars/.
(In reply to Josh Davidson from comment #138) > In Kepler and Luna, I had the same problems described here. I was able to > workaround them (as noted elsewhere in this report via): > -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf. > provider.filetransfer.httpclient > > > However, now that I upgraded to Mars, the workaround no longer works. Most > update sites continue to function. However, I am not able to access any of > the release repositories (e.g.): > http://download.eclipse.org/releases/mars > http://download.eclipse.org/releases/luna > > Other Eclipse update sites work fine > (i.e.http://download.eclipse.org/eclipse/updates/4.5). I've tried the other > workarounds and I couldn't get anything to work. I am behind a corporate > proxy with a snooping SSL cert. I've tried both standalone releases of Mars > and upgrading existing installations. Everything so far fails when trying > to access the release update site. I'm wondering if that > excludeContributers variable changed in Mars. Here is an example stack > trace: > > !SUBENTRY 1 org.eclipse.equinox.p2.metadata.repository 4 1002 2015-06-26 > 07:31:55.106 > !MESSAGE Unable to read repository at > http://download.eclipse.org/releases/mars/. > !STACK 1 > org.eclipse.equinox.p2.core.ProvisionException: No repository found at > http://download.eclipse.org/technology/epp/packages/mars/. > at > org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager. > fail(AbstractRepositoryManager.java:395) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl. > java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.eclipse.oomph.util.ReflectUtil.invokeMethod(ReflectUtil.java:116) > at > org.eclipse.oomph.p2.internal.core.CachingRepositoryManager. > fail(CachingRepositoryManager.java:300) > at > org.eclipse.oomph.p2.internal.core.CachingRepositoryManager. > loadRepository(CachingRepositoryManager.java:196) > at > org.eclipse.oomph.p2.internal.core.CachingRepositoryManager$Metadata. > loadRepository(CachingRepositoryManager.java:394) > at > org.eclipse.equinox.internal.p2.metadata.repository. > MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96) > at > org.eclipse.equinox.internal.p2.metadata.repository. > MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) > at > org.eclipse.equinox.internal.p2.metadata.repository. > CompositeMetadataRepository.addChild(CompositeMetadataRepository.java:166) > at > org.eclipse.equinox.internal.p2.metadata.repository. > CompositeMetadataRepository.<init>(CompositeMetadataRepository.java:106) > at > org.eclipse.equinox.internal.p2.metadata.repository. > CompositeMetadataRepositoryFactory.load(CompositeMetadataRepositoryFactory. > java:122) > at > org.eclipse.equinox.internal.p2.metadata.repository. > MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57) > at > org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager. > loadRepository(AbstractRepositoryManager.java:768) > at sun.reflect.GeneratedMethodAccessor52.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl. > java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.eclipse.oomph.util.ReflectUtil.invokeMethod(ReflectUtil.java:116) > at > org.eclipse.oomph.p2.internal.core.CachingRepositoryManager. > loadRepository(CachingRepositoryManager.java:344) > at > org.eclipse.oomph.p2.internal.core.CachingRepositoryManager. > loadRepository(CachingRepositoryManager.java:146) > at > org.eclipse.oomph.p2.internal.core.CachingRepositoryManager$Metadata. > loadRepository(CachingRepositoryManager.java:394) > at > org.eclipse.equinox.internal.p2.metadata.repository. > MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96) > at > org.eclipse.equinox.internal.p2.metadata.repository. > MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92) > at > org.eclipse.equinox.p2.ui.ProvisioningUI. > loadMetadataRepository(ProvisioningUI.java:440) > at > org.eclipse.equinox.internal.p2.ui.model.MetadataRepositoryElement. > getMetadataRepository(MetadataRepositoryElement.java:126) > at > org.eclipse.equinox.internal.p2.ui.model.MetadataRepositoryElement. > getRepository(MetadataRepositoryElement.java:115) > at > org.eclipse.equinox.internal.p2.ui.model.MetadataRepositoryElement. > getQueryable(MetadataRepositoryElement.java:109) > at > org.eclipse.equinox.internal.p2.ui.QueryProvider. > getQueryDescriptor(QueryProvider.java:88) > at > org.eclipse.equinox.internal.p2.ui.model.QueriedElement. > fetchChildren(QueriedElement.java:101) > at > org.eclipse.equinox.internal.p2.ui.model.MetadataRepositoryElement. > fetchChildren(MetadataRepositoryElement.java:77) > at > org.eclipse.equinox.internal.p2.ui.model.RemoteQueriedElement. > fetchDeferredChildren(RemoteQueriedElement.java:34) > at > org.eclipse.ui.progress.DeferredTreeContentManager$1. > run(DeferredTreeContentManager.java:232) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) > !SUBENTRY 2 org.eclipse.equinox.p2.metadata.repository 4 1000 2015-06-26 > 07:31:55.106 > !MESSAGE No repository found at > http://download.eclipse.org/technology/epp/packages/mars/. Hello, Thnis sounds similatr to the problem reported in bug 470900. The work around suggested is to delete the ~/.eclipse/*oomph* content
(In reply to Josh Davidson from comment #138) > In Kepler and Luna, I had the same problems described here. I was able to > workaround them (as noted elsewhere in this report via): > -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf. > provider.filetransfer.httpclient > > <stuff deleted> > and upgrading existing installations. Everything so far fails when trying > to access the release update site. I'm wondering if that > excludeContributers variable changed in Mars. No, excludeContributors has not changed/is the same. But with Mars, I think you may need to change the property value to exclude httpclient4 rather than httpclient as httpclient4 has been the default provider for a while...e.g: -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4 note the '4' on the end
> Hello, > Thnis sounds similatr to the problem reported in bug 470900. The work around > suggested is to delete the ~/.eclipse/*oomph* content This was the issue. Thanks!
This Bug still exists with the newest Eclipse Neon version: Version: Neon Release Candidate 1 (4.6.0RC1) Build id: 20160519-1933 I tried the following steps: 1. Updated an existing "eclipseinstaller by Oomph". 2. Installed Eclipse Modeling Tools, Product version: Neon, 64 bits 3. Launched it in an empty workspace 4. Tried to invoke Help/ After some time, the false error message "HTTP Proxy Authentication Required: http://www.eclipse.org/modeling/amalgam/downloads/package/modeling/neon/compositeContent.xml" was shown. Are there any ideas to fix that before the next release? Otherwise, is there an workaround?
(In reply to Matthias Albert from comment #142) > This Bug still exists with the newest Eclipse Neon version: > > Version: Neon Release Candidate 1 (4.6.0RC1) > Build id: 20160519-1933 > <stuff deleted> > Are there any ideas to fix that before the next release? No. As described in my previous comments, the cause of this was the move to apache httpcomponents 4.x from 3.x, which changed the handling for some proxies. What's needed is significant changes to the provider code to work around the new apache handling for those proxies (NTLM v2 in particular seems to be an ongoing problem for apache code). There are no resources for such changes and the necessary testing in multiple proxy environments. > Otherwise, is there an workaround? See comment 140 and others. It's possible to defeat the httpclient4 provider with a system property and using the URLConnection (jre) based provider instead. This secondary provider does a better job with some proxies.
This is kind of embarassing, right? I mean, lots of companies force their users to go through a proxy, and having Eclipse to fail because of that seems a huge problem to me. For me, setting "-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4" didn't resolve the problem. Neither did adding the proxy settings to the eclipse.ini file. Right now, the only way I can use Eclipse to synchronize with GIT or Bugzilla is to avoid the proxy by connecting through my 4G. Strangely, the internal browser seems to work even when connected through the proxy... Does it use a different component?
I do not want to stress the embossing part. I know people work hard to make and maintain eclipse. However, It is 2018 and I am using oxygen.2 (the latest). I get the following error when using native proxy settings and clicking the Confirm button on the Eclipse Marketplace page for the Subclipse version 4.2.3 plugin (please note that the proxy work up to that point, i.e. they do not always fail): eclipse.buildId=4.7.2.M20171130-0510 java.version=1.8.0_144 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_CA Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product org.eclipse.equinox.p2.transport.ecf Error Tue Jan 16 13:57:35 EST 2018 HTTP Proxy Authentication Required: https://dl.bintray.com/subclipse/releases/subclipse/4.2.x/compositeContent.xml org.eclipse.ecf.filetransfer.BrowseFileTransferException: Proxy Authentication Required at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientFileSystemBrowser.runRequest(HttpClientFileSystemBrowser.java:291) at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56) Please note that modifying the eclipse.ini to use the -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4 causes the proxy to fail completely. I would like to know if someone can and will look into this problem? It has been around for long enough and affect a lot of corporate users behind authenticating firewall. Note: As a workaround, I was able to set the proxy to manual and the confirm button will then work.
It would be appreciated if someone can provide access to such environment or at least give clean instructions how to come up with such environment (that doesn't include any software to buy) so the issue can be actually tested. Not being able to reproduce it means no work really happens.
When you set username and password to ntlm proxy then this works also in my company: public HttpClient createClient() { HttpHost proxy = new HttpHost(endpointInfo.getProxyHost(), endpointInfo.getProxyPort()); DynamicProxyRoutePlanner routePlanner = new DynamicProxyRoutePlanner(proxy); CredentialsProvider credentialsProvider = new BasicCredentialsProvider(); if (endpointInfo.getProxyUsername() != null && !"".equals(endpointInfo.getProxyUsername())) { NTCredentials ntCredentials = new NTCredentials(endpointInfo.getProxyUsername(), endpointInfo.getProxyPassword(), null, null); credentialsProvider.setCredentials(new AuthScope(endpointInfo.getProxyHost(), endpointInfo.getProxyPort()), ntCredentials); } AuthenticationStrategy targetAuthStrategy = new TargetAuthenticationStrategy(); HttpClientBuilder builder = HttpClientBuilder.create().setRoutePlanner(routePlanner).setTargetAuthenticationStrategy(targetAuthStrategy); if (endpointInfo.getProxyUsername() != null && !"".equals(endpointInfo.getProxyUsername())) { builder.setDefaultCredentialsProvider(credentialsProvider); } HttpClient client = builder.build(); return client; } http-client 4.5.3 But this is not sufficient solution because user would have to change password every month in Preference->General->Network Connections. I have stopped using http client. HttpURLConnection is much better and I don't have to set proxy credentials because HttpURLConnection can get it from OS.
I regret piling on, but more of the same... I have a new Eclipse oxygen.3 on W10Pro. I cannot install Nodeclipse (nor other features) because "connection refused: connect" on .../updates/content.xml. The selected features list gets populated ok, but then fails after Confirm > button. I presume the marketplace content comes via the web, and is visible for me to choose from - I just cannot proceed from there. The same symptoms are present on another box (W7Ultimate), same network, using Eclipse Mars. I went through the Eclipse net config to enable the protocols as manual. I am NOT using a proxy, but am using a firewall appliance. The symptoms on the two boxes merge at the firewall or upstream, but still, the refusal comes from eclipse.org. Is there some Eclipse cred caching I must do, as in Git? I kinda expected a login somewhere in Eclipse but don't find any.
In case you are using Oracle JDK 8 1.8.0_111(and above) 7 1.7.0_121(and above) 6 1.6.0_131(and above) please read this: http://www.oracle.com/technetwork/java/javase/8u111-relnotes-3124969.html "... Disable Basic authentication for HTTPS tunneling In some environments, certain authentication schemes may be undesirable when proxying HTTPS. Accordingly, the Basic authentication scheme has been deactivated, by default, in the Oracle Java Runtime, by adding Basic to the jdk.http.auth.tunneling.disabledSchemes networking property. Now, proxies requiring Basic authentication when setting up a tunnel for HTTPS will no longer succeed by default. If required, this authentication scheme can be reactivated by removing Basic from the jdk.http.auth.tunneling.disabledSchemes networking property, or by setting a system property of the same name to "" ( empty ) on the command line. Additionally, the jdk.http.auth.tunneling.disabledSchemes and jdk.http.auth.proxying.disabledSchemes networking properties, and system properties of the same name, can be used to disable other authentication schemes that may be active when setting up a tunnel for HTTPS, or proxying plain HTTP, respectively. JDK-8160838 (not public) ..."
One work-around that has worked for some commenters on this bug is to replace the default httpcore/httpclient (currently version httpcore->4.4.6/httpclient->4.5.2 for Oxygen.3 and Photon.M6) with the JRE URLConnection-based provider. The mechanism for doing this is documented here: https://wiki.eclipse.org/Disabling_Apache_Httpclient This workaround has worked for some who have experienced this problem...e.g. comment 35 and others. If you haven't tried it already, I suggest giving it a try and reporting the outcome here. If some of you who are experiencing this/these problems are willing, over the next month prior to photon I would be willing to work directly with you to identify what's happening specifically in your environment, and see what can be done to address as many of the underlying issues as possible...whether in httpclient/proxy/ECF/or their interaction. With the caveat that my time to work on this is currently all volunteer and very limited, perhaps with your help (via testing in your network environment) for Photon we can diagnose and deal with some of these issues.
Hi all, consider trying the latest 4.12 I-builds of Eclipse from Thu, 16 May onwards: https://download.eclipse.org/eclipse/downloads/index.html It has a new ECF filetransfer provider implementation and we'd love to know if this improves the situation for you. Thanks
I'm going to assume that the new ECF implementation which include a native fragment for windows solve this problem until someone demonstrates that this is not the case.
