mojohaus / jaxb2-maven-plugin

JAXB2 Maven Plugin
https://www.mojohaus.org/jaxb2-maven-plugin/
Apache License 2.0
106 stars 77 forks source link

jaxb2-maven-plugin breaking my proxy settings #60

Closed RudolfVonKrugstein closed 5 years ago

RudolfVonKrugstein commented 7 years ago

Hi,

I have proxy settings like this:

        <proxy>
          <id>my-proxy</id>
          <active>true</active>
          <protocol>http</protocol>
          <host>my-proxy.de</host>
          <port>8080</port>
          <nonProxyHosts>*.my.com</nonProxyHosts>
        </proxy>

The nonProxyHosts is important, because hosts with *.my.com are not reachable through the proxy. This settings have been tested and work.

Now I have a maven project, with submodules:

    <module>module-using-jaxb2</module>
    <module>module-needing-proxy-settings</module>

The first one uses the jaxb2-maven-plugin.

The second depends on nonProxyHosts being set correctly.

  1. If run this project, module-needing-proxy-settings fails because it tries to reach server.my.com through the proxy (for downloading dependencies).
  2. If i remove the module-using-jaxb2, it works.

So it seems that jaxb2-maven-plugin is breaking the proxy settings of maven.

Any ideas on how and why this is happening?

csamarghitan commented 7 years ago

I have a similar issue, after the maven module with the jaxb2-maven-plugin runs, the proxy settings are all messed up. Did you find a solution for this issue?

lennartj commented 7 years ago

Seems like a clear bug. Could you provide an IT for this situation?

csamarghitan commented 7 years ago
  1. We noticed that if we add the -Dhttp.nonProxyHosts="*.excluded.hostname" to the command line it works, but it's not very nice and can be problematic in an IDE
  2. One small detail in AbstractJavaGeneratorMojo.getProxyString() there should be a check of empty string for the username and the password
  3. We think the issue is from one of the dependencies of the plugin, maybe XJC.
Here are the obfuscated arguments passed to XJC: `+=================== [13 XJC Arguments] [0]: -xmlschema [1]: -httpproxy [2]: :@proxyweb.domain.name:8082 [3]: -encoding [4]: UTF-8 [5]: -p [6]: domain.name.standalone.model [7]: -d [8]: /path-to-target/target/generated-sources [9]: -extension [10]: -episode [11]: /path-to-target/target/generated-sources/META-INF/sun-jaxb.episode [12]: disp-app/src/main/resources/xsd/App.xsd

+=================== [End 13 XJC Arguments]`

I'll try to create a test scenario, but you will have to have a proxy.

csamarghitan commented 7 years ago

Here is a sample project. If you don't have a proxy you can set the proxy in your settings.xml like this: `

optional true http proxy.host.net 80 *

` The nonProxyHosts is set to * so it will not use the proxy. But if the value is erased it will try to use the proxy and fail. maven-test.tar.gz

fpiecka commented 7 years ago

We have a similar problem which seems to be triggered by the same bug.

We found the problem by accidentaly misconfiguring proxy settings in Maven.

We had this in the Maven configuration (names/hostnames have been anonymized):

<proxies>
    <proxy>
      <id>example-proxy</id>
      <active>false</active>
      <protocol>https</protocol>
      <host>proxy.example.com</host>
      <port>8080</port>
      <nonProxyHosts>*.example.com</nonProxyHosts>
    </proxy>
</proxies>

There is HTTP protocol configuration missing. It worked for most of our builds (which is expected, because we use an internal Nexus for public repositories caching on HTTPS). No build probably tried HTTP connections outside our network.

However there was a problem with a single project/build, whixh requires jaxb2--maven-plugin. It tried to reach our nexus installation at https://nexus.example.com:8081/nexus/ through proxy. It seems it absolutely ignored Maven config nonProxyHosts directive.

The strange thing happened, when we corrected our configuration by including HTTP protocol. The correct configuration now is:

<proxies>
    <proxy>
      <id>example-proxy-http</id>
      <active>false</active>
      <protocol>http</protocol>
      <host>proxy.example.com</host>
      <port>8080</port>
      <nonProxyHosts>*.example.com</nonProxyHosts>
    </proxy>
    <proxy>
      <id>example-proxy</id>
      <active>false</active>
      <protocol>https</protocol>
      <host>proxy.example.com</host>
      <port>8080</port>
      <nonProxyHosts>*.example.com</nonProxyHosts>
    </proxy>
</proxies>

With this configuration, the build using jaxb2-maven-plugin works and correctly connects directly to our Nexus server. Thus bypassing the proxy and obeying nonProxyHosts.

It seems as if the HTTP proxy nonProxyHosts value was used for HTTPS connections.

arleth commented 6 years ago

Hi thanks - by adding both http & https proxies like in the example I also got it to work together with maven 3.5.2 - it started failing after I upgraded from maven 3.0.5...

joostoudeman commented 6 years ago

I would like to add my experience, there might be a patch possible. The real problem seems to come from the Jaxb XJC library. My experience was the proxy being used when it shouldn't be.

I traced it like this: org.codehaus.mojo.jaxb2.javageneration.AbstractJavaGeneratorMojo#performExecution is calling com.sun.tools.xjc.Driver#run(java.lang.String[], com.sun.tools.xjc.XJCListener) which is calling com.sun.tools.xjc.Options#parseArguments.

This method doesn't even support supplying the http.nonProxyHosts. Only if JAXB-XJC is patched can there be a clean solution. For now I placed the http.nonProxyHosts in my environment variables directly, and this works, but it would be desirable if it works out of the box.

My guess, the developers might be able to work around it, but never very clean.

kaszuster commented 5 years ago

Experienced the exact same thing as @arleth. We Upgraded from Maven 3.0.5 to 3.5.4, from there on the build breaks. Keeping the configuration and switching between these versions gives me the same results 3.5.x broken 3.0.5 works.

The Plugin-Configuration looks something like this:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>jaxb2-maven-plugin</artifactId>
    <version>2.4</version>
    <executions>
        <execution>
            <id>xsd2java</id>
            <phase>generate-sources</phase>
            <goals>
                <goal>xjc</goal>
             </goals>
             <configuration>...</configuration>
        </execution>
    </executions>
</plugin>

Will implement the http.nonProxyHosts solution with the drawback @joostoudeman mentioned

... never very clean

efeat commented 5 years ago

Hi all,

jaxb2-maven-plugin:2.4 also breaks my maven:3.6.0 proxy settings on java:1.8.0_111 which are looking like this:

 <mirrors>
     <mirror>
        <id>my-mirror</id>
        <mirrorOf>*</mirrorOf>
        <url>https://repository.my.com</url>
      </mirror>
  </mirrors>

  <proxy>
      <id>my-proxy</id>
      <active>true</active>
      <protocol>http</protocol>
      <host>my-proxy.de</host>
      <port>8080</port>
      <nonProxyHosts>*.my.com</nonProxyHosts>
  </proxy>

Artifacts can't be downloaded after the xjc goal call because wagon tries to join our internal repository throught our proxy. It's comming from the com.sun.tools.xjc.OptionsEx.parseArguments call which directly modifies the jvm properties (:-1:) without setting the nonProxyHosts (:-1: :-1:):

optionsex

Unfortunately wagon-http uses sun.net.spi.DefaultProxySelector class to select the appropriate proxy for a target url. This selector also uses jvm properties to choose its proxy:

systemdefaultrouteplanner

The solution proposed by @fpiecka does not work for me because the proxy must be disabled and it breaks my org.owasp:dependency-check-maven:5.0.0-M1:check goal:

dependency-check-maven

The single solution I've found is to change of wagon implementation:

    <build>
        ...
        <extensions>
            <extension>
                <groupId>org.apache.maven.wagon</groupId>
                <artifactId>wagon-http-lightweight</artifactId>
                <version>3.3.2</version>
            </extension>
        </extensions>
        ...
    </build>

I would prefer a better one!

efeat commented 5 years ago

In my opinion the simplest way to correct this issue is to fork the jvm in the org.codehaus.mojo.jaxb2.javageneration.AbstractJavaGeneratorMojo.performExecution()method.

shelgen commented 5 years ago

I tried out just restoring the original values of the properties after executing XJC, and that seemed to resolve the issue. Added a PR.