[ 
http://jira.codehaus.org/browse/SUREFIRE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brett Porter updated SUREFIRE-109:
----------------------------------

    Fix Version/s:     (was: 2.3)
                   2.4

> VM Forking manifests itself behind HTTP proxy
> ---------------------------------------------
>
>                 Key: SUREFIRE-109
>                 URL: http://jira.codehaus.org/browse/SUREFIRE-109
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: classloading, plugin
>    Affects Versions: 2.3
>         Environment: win2k, java 1.5
>            Reporter: Ben Hood
>             Fix For: 2.4
>
>         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

        

Reply via email to