[jira] Commented: (MSUREFIRE-161) VM Forking manifests itself behind HTTP proxy
[ 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: > > > > org.apache.maven.plugins > maven-surefire-plugin > > never > > > > > 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
[jira] Commented: (MSUREFIRE-161) VM Forking manifests itself behind HTTP proxy
[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=comments#action_77026 ] Ben Hood commented on MSUREFIRE-161: I just turned the forking off, as indicated above. In my case, it was better to have no forking because of the amount of tests run, but if I did need to fork for some reason, then I couldn't use maven to test (at least from behind an http proxy). I think this just indicates a bug in the resource resolution. > 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: > > > > org.apache.maven.plugins > maven-surefire-plugin > > never > > > > > 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
[jira] Commented: (MSUREFIRE-161) VM Forking manifests itself behind HTTP proxy
[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=comments#action_77025 ] Ronny Naess commented on MSUREFIRE-161: --- I do not blame you :-) It was I that linked the two dependencies on top. I just commented in the comment field, but I had now idea it would come out this way. Ignor may last comment and just look at my previoud post. Anyway, I have simulare problemes like the one you experienced. My test-jars (created in pom) which is to be included when running tests in other artifacts, has test resources to be used at test runtime. If i run install from top level (parent pom) my build is almost never success. My test deps is included and used in the test classpath for the first artifacts, but then it suddenly breaks even it says it is there. It breaks because test resources is not found. This is a random behavior since it later can work, and or a previous successfully built artifact may break the second time. Very frustrating all very random. It is very easy to see that this is a random error. We have resources that is the same for both main and test, that is same filenames for the resources, but different content. I list the content to screen at test runtime. Until the problem is problem is solved we have skipped the testing in maven. Did you ever solve your problems in a useful way? > 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: > > > > org.apache.maven.plugins > maven-surefire-plugin > > never > > > > > 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
[jira] Commented: (MSUREFIRE-161) VM Forking manifests itself behind HTTP proxy
[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=comments#action_77006 ] Ben Hood commented on MSUREFIRE-161: Ronny, I'm sorry, I don't understand your question at all. Could you elaborate? Regards, Ben > 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: > > > > org.apache.maven.plugins > maven-surefire-plugin > > never > > > > > 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
[jira] Commented: (MSUREFIRE-161) VM Forking manifests itself behind HTTP proxy
[ 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: > > > > org.apache.maven.plugins > maven-surefire-plugin > > never > > > > > 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
