[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=comments#action_76995 ] Ronny Naess commented on MSUREFIRE-161: ---------------------------------------
I think this is the same issue as in http://jira.codehaus.org/browse/MSUREFIRE-115 and maybe http://jira.codehaus.org/browse/MSUREFIRE-121. I think this smells like an blocker more than not, at least critical. > 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 > Components: classloading > Affects Versions: 2.3 > Environment: win2k, java 1.5 > Reporter: Ben Hood > Fix For: 2.3 > > 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
