Proxy support not working if using the environment

[ph]

I am currently looking to add the proxy support back into logstash 1.5, but I am unable to make the jars download uses a proxy. I was expecting setting the http_proxy env variable to an appropriate proxy and the libs management would pick it up.

Versions:

• jar-dependencies 0.1.7
• ruby-maven 3.1.1.0.8

Scenarios

1. I've looked a bit at the codebase of both rubygems and jar-dependencies, the current implementation of jar-dependencies uses the Gem.configuration[:proxy] but in the rubygems test suite they uses Gem.configuration[:http_proxy]. After making my code update both the http_proxy and the proxy key and adding trace I see that my configuration is correctly send to the mvn class loader (in ruby maven) but the jar download isn't using the proxy.
2. If I create a a simple settings.xml and set the JARS_MAVEN_SETTINGS to use it, it doesn't go to the proxy..
3. If I move the same settings.xml file in the ~/.m2 directory, the jars download will go through the proxy

Settings.xml

<settings>
  <proxies>
   <proxy>
      <id>example-proxy</id>
      <active>true</active>
      <protocol>http</protocol>
      <host>127.0.0.1</host>
      <port>3128</port>
    </proxy>
  </proxies>
</settings>

Logstash ref: https://github.com/elastic/logstash/issues/2851

[ph]

Ref: https://github.com/elastic/logstash/issues/2851

Rubygems test suite for the http_proxy key: https://github.com/rubygems/rubygems/blob/beff2d684c12b97421343d5970906609a8d78f7a/test/rubygems/test_gem_request.rb#L31-L35

[mkristian]

fixed the maven-settings issue.

the proxy support from Gem.configuration is still pending - not sure yet how to fix it

[ph]

@mkristian This is still an issue today (jar dependencies 0.3.5), I've run into it and I have a setup to reproduce it. Do you want to reopen it or create a new one?

I am using a 2 vagrant VM, one with squid3 and the other vm only has access to the squid proxy. When I create the settings.xml it fixes the problem.

#/etc/squid3/squid.conf
#Recommended minimum configuration:
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8
acl localnet src 0.0.0.0/8 192.168.100.0/24 192.168.1.0/24
acl SSL_ports port 443
acl Safe_ports port 80      # http
acl Safe_ports port 21      # ftp
acl Safe_ports port 443     # https
acl Safe_ports port 70      # gopher
acl Safe_ports port 210     # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280     # http-mgmt
acl Safe_ports port 488     # gss-http
acl Safe_ports port 591     # filemaker
acl Safe_ports port 777     # multiling http

acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports

http_access deny to_localhost
icp_access deny all
htcp_access deny all

http_port 3128
hierarchy_stoplist cgi-bin ?
access_log /var/log/squid3/access.log squid

#Suggested default:
refresh_pattern ^ftp:       1440    20% 10080
refresh_pattern ^gopher:    1440    0%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern .       0   20% 4320
# Leave coredumps in the first cache dir

[mkristian]

@ph will look into this asap

[suyograo]

@mkristian any ETA on when we can expect a new version with #16? Thanks much for the fix.

[mkristian]

@suyograo getting the tests green on the weekend and then I release it and update jruby to bundle the new release

[suyograo]

@mkristian we included 0.3.7 in Logstash 5.1.1, and a user is reporting what looks like a bug in jar_dependencies. See https://github.com/elastic/logstash/issues/6396 for details.