[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=comments#action_82918 ] Kenney Westerhof commented on MSUREFIRE-161: --------------------------------------------
Removed links to other issues, as this is not a classloading issue. The error is 'unknownknostexception: www.springframework.org'. This has something to do with DNS and proxies, not with classloading. My guess is that you've set some HTTP_PROXY env var that's available to maven/the jvm running maven, but isn't to the forked unit test. What's your exact setup? Unless org.springframework.beans.factory.xml.DefaultDocumentLoader.loadDocument(DefaultDocumentLoader.java:66) uses some resource file to feed the dns (impossible) or configure a proxy, I don't see the classloading issue here. Could you try to insert a typo in the DTD location, for instance 'xxx.springframework.org', and run the test without forking, to see what kind of stacktrace you get? It should be different from this one. > 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
