Skip to content
Snippets Groups Projects

RCP: X.X, proxy settings in TXM and its components

    • Closed Issue created by Matthieu Decorde @mdecorde

    TXM can encounter proxy issues at various moments :

    • during installation when:
      • dependencies are installed (Linux) ->OS configuration
      • installation of R packages (Linux + Mac OS X) ->R configuration #1116 (closed)
    • during first launch of TXM when
      • java proxy configures itself: native mode->RCP configuration
      • updates are fetch during start-up ->[NOTE: updates are not fetched anymore at first launch in the new setups]
      • welcome page is shown ->RCP configuration
    • during next launches of TXM when
      • updates are fetch during start-up ->RCP configuration #1036
      • when user call the “Check R packages” command ->R configuration #857

    See child tickets for details.

    Solution

    1. MD: produce setups Alpha
    2. SJ: test proxy for the 3 proxy moments and OS

    Special note on Windows proxy configuration and RCP

    If I remember well, there is a “bug” in the RCP related to the priority order of the used proxy, the SOCKS proxy is always used as the first. In Windows OS you can define the HTTP proxy then check “Use the same proxy for all protocols”. If the user checks this option, it leads to some bugs in the RCP because of this priority problem. For the tests below, if this option is checked, the RCP updates won’t work. After investigations, on Windows XP, checking the option “Use the same proxy for all protocols” define the SOCKS proxy as the same as the HTTP proxy but on Windows 7, checking the option leaves the SOCKS proxy as empty. That’s why my first tests were successful on Seven but not on XP. We may find a way to change the priority proxies order in the RCP or to disable the SOCKS proxy ? The tests below on Windows are now done without the SOCKS proxy defined but the best solution really would be to change the priority order.

    If the SOCKS proxy is set in the RCP, I keep having these messages in console and the RCP updates functions don’t work:

    org.apache.httimpl.DefaultRequestDirector tryConnect
INFOS: Retrying connect
INFOS: I/O exception (java.net.SocketException) caught when connecting to the target host: Malformed reply from SOCKS server

    Tests updates fetching behavior with Eclipse Luna and proxy

    No hang up with Luna + MAC OS X + Proxy + auto fetching updates at start up

    (from redmine: issue id 1022, created on 2014/09/29 by Matthieu Decorde)

    Edited

    Designs

    Child items ...

    • Activity

    • Matthieu Decorde added connectivity type::feature + 1 deleted label

      added connectivity type::feature + 1 deleted label

    • Matthieu Decorde changed milestone to %TXM 0.7.7

      changed milestone to %TXM 0.7.7

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      About Mac OS X:

      - see comment #9 here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=330691
      about a proxy bug in Eclipse under Mac OS X

      • it seems there is no existent Eclipse native plug-in to manage system proxies for Mac OS ? (as org.eclipse.core.net.win32.x86_64)

      (from redmine: written on 2014/10/09 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      LINUX, Ubuntu 13.04 and proxy (VM)

      • during installation when:
        • dependencies are installed ->OK
        • installation of R packages ->OK
      • during first launch of TXM when
        • java proxy configures itself: native mode ->OK
        • welcome page is shown ->OK
      • during next launches of TXM when
        • updates are fetch during start-up ->OK
        • when user calls the “Check R packages” command ->OK
      • Complementary tests
        • when user calls the “Check for updates” command ->OK
        • when user calls the “Add an extension” command ->OK

      (from redmine: written on 2014/11/19 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      MAC OS X and proxy (VM)

      NOTE: about proxy, the same behavior than TXM occurs in Luna, if a system proxy is set, the active provider is not set as “Manual” at first launch

      NOTE found in /System/Library/Frameworks/JavaVM.framework/Home/lib/net.properties

      # Whether or not the DefaultProxySelector will default to System Proxy
# settings when they do exist.
# Set it to 'true' to enable this feature and check for platform
# specific proxy settings
# Note that the system properties that do explicitely set proxies
# (like httproxyHost) do take precedence over the system settings
# even if java.net.useSystemProxies is set to true.

# MacOSX:
# On MacOSX, setting java.net.useSystemProxies to true or false is a no-o
# Proxy settings from System Preferences are always used and they override any
# settings specified in this file. Values from this file are only used if there
# are no proxy settings in System Preferences.
# See Release Notes for more information.

java.net.useSystemProxies=false
      • during installation when:

      installation of R packages ->OK

      • during first launch of TXM when
        • java proxy configures itself: native mode ->The active provider is not set as “native”. It’s set as “direct” and the HTTP system proxy is well defined in the “Proxy entries list” but not checked, therefore we may: 1) directly set the provider as “Manual” and check the HTTP proxy if exists 2) tell users to do the manipulation

      Current state, test #1:

      - manually put active provider as “Manual”

      - “Add an extension” =>seems OK

      • “Check for updates” =>null pointer exception (with no hang up)
        It appears that if I set:

        System.setProperty("httproxySet", "true");

      in a groovy script, the “Check for updates” function works. See: http://blog.vogella.com/2009/12/08/eclipse-rcp-proxy-preference/

      • trying to set active provider as “Manual” through code doesn’t seem to work, tried the following in a groovy script:

        proxyService.setProxiesEnabled(true);

      • when relaunching TXM, the “Manual” preference is not read, the active provider is set back to “Direct”. But the pref seems to be well saved in TXM\configuration\.settings\org.eclipse.core.net.prefs as follow:

        proxiesEnabled=true

      welcome page is shown ->OK

      //TODO :
      These tests has been done after having manually set the active provider to “Manual” instead of “Direct” through the preference Tools\Parameters\General\Network Connections\

      WARNING: if the proxy has not been set, at 2nd launch of TXM we still have the time out problem at splash screen when TXM tries to connect via HTTP. The duration was about 4min30 during my last tests. It means the updates fetching process is still neither UI thread independent nor cancelable through UI. It also means the problem may be present on all OS and also in the case where the connexion parameters are wrong, e.g. : having set a bad proxy or a proxy while machine is directly connected to the Internet

      If we can’t set ourself the active provider as “Manual” at first launch we could do :

      • edit ourself the org.eclipse.core.net.prefs file (be careful, since we store the plugins in the TXM install directory, this file is duplicated in RCP user directory (.txm) AND TXM install directorie) and fill in with system proxy data :

        proxyData/HTTP/hasAuth=false proxyData/HTTP/host=proxy.domaine.fr proxyData/HTTP/port=3128 systemProxiesEnabled=false

      - create user tutorial about setting the active provider as “Manual” at first launch instead of “Direct”

      • during next launches of TXM when
        • updates are fetch during start-up ->OK
        • when user calls the “Check R packages” command ->OK
      • Complementary tests
        • when user calls the “Check for updates” command ->OK
        • when user calls the “Add an extension” command ->OK

      (from redmine: written on 2014/11/19 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      WINDOWS XP 32bit and proxy

      NOTE: these tests has been done without the SOCKS proxy configured in the OS.
      NOTE: there is no more splash screen under Windows OS.
      NOTE: the tests has been successfully passed using a .pac proxy configuration file too.

      • during first launch of TXM when
        • java proxy configures itself: native mode ->OK
        • updates are fetch during start-up ->seems OK
        • welcome page is shown ->OK
      • during next launches of TXM when
        • updates are fetch during start-up ->OK
        • when user calls the “Check R packages” command ->FAILED, TXM hangs up until the R time out then says “update of ‘textometry’ failed”
      • Complementary tests
        • when user calls the “Check for updates” command ->seems OK (no updates were found) (Need to add a popup ?)
        • when user calls the “Add an extension” command ->seems OK (the windows of extensions user can install well opens)

      I had a lot of reboots when manipulating the TXM UI (ex. go to Tools\Parameters at first launch), I don’t know if the problem is the old machine and/or the new RCP 4.4.1 usage.

      (from redmine: written on 2014/11/19 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      WINDOWS 7 64bit (Java 1.8, machine #2) and proxy

      NOTE: there is no more splash screen under Windows OS.

      • during first launch of TXM when
        • java proxy configures itself: native mode ->OK
        • updates are fetch during start-up ->seems OK but no message in log
        • welcome page is shown ->OK
      • during next launches of TXM when
        • updates are fetch during start-up ->OK
        • when user calls the “Check R packages” command ->FAILED, TXM hangs up until the R time out then says “update of ‘textometry’ failed”
      • Complementary tests
        • when user calls the “Check for updates” command ->seems OK (no updates were found) (Need to add a popup ?)
        • when user calls the “Add an extension” command ->seems OK (the windows of extensions user can install well opens)

      (from redmine: written on 2014/11/20 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      WINDOWS 7 64bit (Java 1.7, machine #1) and proxy

      NOTE: there is no more splash screen under Windows OS.

      • during first launch of TXM when
        • java proxy configures itself: native mode ->OK
        • updates are fetch during start-up ->OK
        • welcome page is shown ->OK
      • during next launches of TXM when

        • updates are fetch during start-up ->OK
          log: Starting update fetch Update levels: dev=false alpha=false beta=false Test if install directory rights are correct: read&write Ready to show Update UI Effectué en 3 sec. No update available.

        • when user calls the “Check R packages” command ->OK => Pop up: “Necessary packages are ready”

      • Complementary tests
        • when user calls the “Check for updates” command ->OK => Console: “No update available” (Need to add a popup ?)
        • when user calls the “Add an extension” command ->seems OK =>the windows of extensions user can install well opens

      NOTE: after a restart needed by the adding of the “CheckTXM” extension I had a little hang up and these errors:

      Starting update fetch
déc. 09, 2014 3:40:14 PM org.apache.httimpl.client.DefaultRequestDirector tryConnect
INFOS: I/O exception (java.net.SocketException) caught when connecting to the target host: Network is unreachable: connect
déc. 09, 2014 3:40:14 PM org.apache.httimpl.client.DefaultRequestDirector tryConnect
INFOS: Retrying connect
déc. 09, 2014 3:40:35 PM org.apache.httimpl.client.DefaultRequestDirector tryConnect
INFOS: I/O exception (java.net.SocketException) caught when connecting to the target host: Network is unreachable: connect
déc. 09, 2014 3:40:35 PM org.apache.httimpl.client.DefaultRequestDirector tryConnect
INFOS: Retrying connect
Update levels: dev=true alpha=true beta=true
Could not add update ALPHA repository: http://txm.textometrie.org/updates/TXMalpha
org.eclipse.core.runtime.OperationCanceledException
    at org.eclipse.equinox.internal.p2.repository.CacheManager.updateCache(CacheManager.java:370)
    at org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:208)
    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.txm.rcpapplication.p2.plugins.TXMUpdateHandler.addURL(TXMUpdateHandler.java:248)
    at org.txm.rcpapplication.p2.plugins.TXMUpdateHandler.addDefaultUpdateSites(TXMUpdateHandler.java:210)
    at org.txm.rcpapplication.p2.plugins.TXMUpdateHandler.execute(TXMUpdateHandler.java:85)
    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.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:343)
    at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:330)
    at org.txm.rcpapplication.ApplicationWorkbenchAdvisor$3$1.run(ApplicationWorkbenchAdvisor.java:561)
    at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:167)
    at org.eclipse.ui.internal.UISynchronizer$3.run(UISynchronizer.java:165)
    at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
    at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136)
    at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4147)
    at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3764)
    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.txm.rcpapplication.Application.run(Application.java:152)
    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.internal.apEclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
    at org.eclipse.equinox.internal.apEclipseAppHandle.run(EclipseAppHandle.java:198)
    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:380)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
    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)
Test if install directory rights are correct: read&write
Ready to show Update UI

      OK, now I have a 15-20 secs hang up every time I start TXM, log:

      Starting Charts Engine
Toolbox states: cqp:true R :true Espace de travail : true
Initializing the charts SWT component provider
Loading views
Prêt.
Effectué en 10 sec (10487).
Starting update fetch
Update levels: dev=true alpha=true beta=true
Test if install directory rights are correct: read&write
Ready to show Update UI
Effectué en 19 sec.

      (from redmine: written on 2014/12/09 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      Some news:

      - the time out used by the P2 updates system is set by the org.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout system property (15000 ms by default)

      - see https://wiki.eclipse.org/Equinox/p2/TransportDebugging for more informations

      • see the number of retries properties too

      (from redmine: written on 2015/02/09 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      P2 uses the JRE-http based transport or the Apache httpclient.
      After some tests, it keeps unclear for me when Eclipse uses one or the other, it’s proxy related.
      It seems using for example:

       proxyService.setProxiesEnabled(true);
 proxyService.setSystemProxiesEnabled(false);

      switches Eclipse to use the Apache httpclient.

      Since Eclipse 4.3 the Apache httpclient was renamed httpclient4, see https://wiki.eclipse.org/Disabling_Apache_Httpclient.
      I propose to force the JRE-http based transport by adding in TXM.ini:

      -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4

      it would ensure that the time out defined by:

      -Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=1000

      is used.
      The other solution may be to specify the time out for the Appache httpclient too:
      -Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=1000
      -Dorg.eclipse.ecf.provider.filetransfer.httpclient4.retrieve.connectTimeout=1000

      The first solution tested on Mac OS X VM + proxy seems to work fine. The second solution doesn’t seem to work. Need to do more tests for the Beta 2.

      (from redmine: written on 2015/02/20 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      Some new validations tests on two clean machines.

      1. Windows 7 64bit with dynamic proxy system configuration (.pac file) =>All tests OK
        * the provider is set to “dynamic” in RCP preferences
      2. Windows 7 64bit with no network connection at all =>All tests “OK”
        NOTE: there’s no waiting time at all when machine is not connected and not configured (unlike when a system proxy is configured in the OS but not in TXM).
        The console messages may be more user friendly, actually there are only some stack trace of null or error exceptions.

      (from redmine: written on 2015/03/25 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      NOTE: When using a captive portal, TXM welcome page request is redirected to the captive portal login page, often in HTTPS, leading to a potential security warning about the certificate (SWT Browser + Internet Explorer)

      (from redmine: written on 2015/04/02 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      The argument:

      -Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=1000

      may be increased in:

      -Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=2000

      or:

      -Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=1500

      for more robustness when updating TXM with slow connections.

      This issue must also be validated by executing a TXM update with proxy, without proxy, with bad connection settings, without connection at all, and more ?

      (from redmine: written on 2015/04/23 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      Some docs about the ECF Filetransfer support: https://wiki.eclipse.org/ECF_Filetransfer_Support_for_NTLMv2_Proxies

      (from redmine: written on 2015/05/15 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      New current state of the art of the VM args in last SVN related to the ECF filetransfer provider used by RCP/P2 update system:

      -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=10000
-Dorg.eclipse.ecf.provider.filetransfer.browse.connectTimeout=20000
-Dorg.eclipse.ecf.provider.filetransfer.browse.readTimeout=10000
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.closeTimeout=20000
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.readTimeout=20000
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.retryAttempts=2
-Dsun.net.client.defaultReadTimeout=30000

      The retrieve connect time out seems to have been re-raised to 10000ms which may roll back the bug encountered with proxy systems especially wrong RCP proxy configuration.
      I’ll try do some tests on proxy with these parameters to see if they are problematic before we build the next setup 0.7.7b2.

      (from redmine: written on 2015/05/15 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      Test results on Windows XP with:

      -Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclient4
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.connectTimeout=3000
-Dorg.eclipse.ecf.provider.filetransfer.retrieve.retryAttempts=2

      and proxy not configured in RCP preferences.

      TXM hangs up about 1-2 min after having initialized the TBX.
      In think this is reasonable with these parameters that seem a good balance bewteen proxy users et non proxy users with low connection. I guess 3 seconds is sufficient for low connections.
      I’m going to do some tests on Mac OS X.

      The p2 update job still freezes the UI, is it possible to run it asynchronously ? (which will permit to the user to simply cancel it)

      (from redmine: written on 2015/05/22 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      The blocking process of p2 starts near the first line of this log:

      No repo - create a new artifact repo
Error while adding artifact repo: http://txm.textometrie.org/updates/TXM
org.eclipse.equinox.p2.core.ProvisionException: Communication with repository at http://txm.textometrie.org/updates/TXM failed.
    at org.eclipse.equinox.internal.p2.repository.CacheManager.createCache(CacheManager.java:151)
    at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepositoryFactory.getLocalFile(SimpleArtifactRepositoryFactory.java:65)
    at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepositoryFactory.load(SimpleArtifactRepositoryFactory.java:88)
    at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepositoryFactory.load(SimpleArtifactRepositoryFactory.java:76)
    at org.eclipse.equinox.internal.p2.artifact.repository.ArtifactRepositoryManager.factoryLoad(ArtifactRepositoryManager.java:73)
    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.artifact.repository.ArtifactRepositoryManager.loadRepository(ArtifactRepositoryManager.java:104)
    at org.eclipse.equinox.internal.p2.artifact.repository.ArtifactRepositoryManager.loadRepository(ArtifactRepositoryManager.java:100)
    at org.txm.rcpapplication.p2.plugins.TXMUpdateHandler.addURL(TXMUpdateHandler.java:264)
    at org.txm.rcpapplication.p2.plugins.TXMUpdateHandler.addDefaultUpdateSites(TXMUpdateHandler.java:172)
    at org.txm.rcpapplication.p2.plugins.TXMUpdateHandler.execute(TXMUpdateHandler.java:85)
    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.txm.rcpapplication.Application.run(Application.java:152)
    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.internal.apEclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
    at org.eclipse.equinox.internal.apEclipseAppHandle.run(EclipseAppHandle.java:198)
    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:380)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
    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: java.net.SocketTimeoutException: connect timed out
    at java.net.TwoStacksPlainSocketImpl.socketConnect(Native Method)
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
    at java.net.Socket.connect(Socket.java:579)
    at sun.net.NetworkClient.doConnect(NetworkClient.java:178)
    at sun.net.www.httHttpClient.openServer(HttpClient.java:432)
    at sun.net.www.httHttpClient.openServer(HttpClient.java:527)
    at sun.net.www.httHttpClient.<init>(HttpClient.java:211)
    at sun.net.www.httHttpClient.New(HttpClient.java:308)
    at sun.net.www.httHttpClient.New(HttpClient.java:326)
    at sun.net.www.protocol.httHttpURLConnection.getNewHttpClient(HttpURLConnection.java:996)
    at sun.net.www.protocol.httHttpURLConnection.plainConnect(HttpURLConnection.java:932)
    at sun.net.www.protocol.httHttpURLConnection.connect(HttpURLConnection.java:850)
    at org.eclipse.ecf.provider.filetransfer.browse.URLFileSystemBrowser.runRequest(URLFileSystemBrowser.java:113)
    at org.eclipse.ecf.provider.filetransfer.browse.AbstractFileSystemBrowser$DirectoryJob.run(AbstractFileSystemBrowser.java:69)
    at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Update levels: dev=false alpha=false beta=false
Test if install directory rights are correct: read&write
Ready to show Update UI

      After waiting a few when UI is freezed, and the excetpions are shown, the p2 dialog process then open in a non blocking way. I guess there is a blocking process before this log.

      (from redmine: written on 2015/05/22 by Sebastien Jacquot)

    • Sébastien Jacquot
      Sébastien Jacquot @sjacquot ·
      Owner

      It seems you can define proxy settings without store them in env var for a specific command in Ubuntu using for example:

      http_proxy=http://10.1.3.1:8080 apt-get update

      (from redmine: written on 2015/05/29 by Sebastien Jacquot)

    • Matthieu Decorde mentioned in issue #1116 (closed)

      mentioned in issue #1116 (closed)

    • Sébastien Jacquot changed the description

      changed the description

    • Matthieu Decorde closed

      closed

    • Sébastien Jacquot assigned to @sjacquot

      assigned to @sjacquot

    • Sébastien Jacquot mentioned in issue #525 (closed)

      mentioned in issue #525 (closed)

    Please register or sign in to reply