VM Forking manifests itself behind HTTP proxy
---------------------------------------------
Key: MSUREFIRE-161
URL: http://jira.codehaus.org/browse/MSUREFIRE-161
Project: Maven 2.x Surefire Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: win2k, java 1.5
Reporter: Ben Hood
Attachments: mvn_trace.txt
I have reason to believe that the forking behaviour of the surefire execution
has adverse effects when executed behind an HTTP proxy in combination with DTD
resolution (e.g. the loading of Spring beans).
Whilst using surefire to test a project (the acegi module from the mule
project, svn respo : http://svn.codehaus.org/mule/trunk/mule/modules/acegi ,
revision 2859) I was getting DTD resolution errors (see attached trace).
I orginally posted this over at Spring:
http://opensource.atlassian.com/projects/spring/browse/SPR-2466.
Trying to get Eclipse to attach to the Maven debug process I set up (i.e.
running maven with MAVEN_OPTS="-Xdebug -Xnoagent
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8787"), I found out
that this won't work because the plugin executing the code forks a new VM.
After telling the maven surefire-plugin not to fork with this setting:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkMode>never</forkMode>
</configuration>
</plugin>
</plugins>
</build>
the problem with the DTD resolution from Spring went away.
Under normal circumstances, the DTD should get resolved from within the
classpath, as it is bundled in the jar.
So therefore I conclude that it is indeed a maven classloading / VM issue and
not a Spring issue as first thought.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
