You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Ben Hood (JIRA)" <ji...@codehaus.org> on 2006/08/30 17:28:48 UTC
[jira] Created: (MSUREFIRE-161) VM Forking manifests itself behind
HTTP proxy
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
[jira] Commented: (MSUREFIRE-161) VM Forking manifests itself
behind HTTP proxy
Posted by "Ben Hood (JIRA)" <ji...@codehaus.org>.
[ 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:
> <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
[jira] Updated: (MSUREFIRE-161) VM Forking manifests itself behind
HTTP proxy
Posted by "fabrizio giustina (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=all ]
fabrizio giustina updated MSUREFIRE-161:
----------------------------------------
Fix Version/s: 2.3
Component/s: classloading
> 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
[jira] Commented: (MSUREFIRE-161) VM Forking manifests itself
behind HTTP proxy
Posted by "Ronny Naess (JIRA)" <ji...@codehaus.org>.
[ 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:
> <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
[jira] Closed: (SUREFIRE-109) VM Forking manifests itself behind
HTTP proxy
Posted by "Dan Fabulich (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Fabulich closed SUREFIRE-109.
---------------------------------
Resolution: Incomplete
Fix Version/s: (was: 2.4)
This isn't enough information to reproduce the problem; as Kenney suggested, it's reasonable to think that the bug is related to your network configuration. If possible, please provide a reduced test case (in the form of an archive of a minimal Maven project) that reproduces the problem.
> 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
> 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
[jira] Updated: (SUREFIRE-109) VM Forking manifests itself behind
HTTP proxy
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter updated SUREFIRE-109:
----------------------------------
Affects Version/s: (was: 2.0 (2.2 plugin))
2.3
Component/s: classloading
> 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.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
[jira] Commented: (MSUREFIRE-161) VM Forking manifests itself
behind HTTP proxy
Posted by "Kenney Westerhof (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Commented: (MSUREFIRE-161) VM Forking manifests itself
behind HTTP proxy
Posted by "Ben Hood (JIRA)" <ji...@codehaus.org>.
[ 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:
> <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
[jira] Commented: (MSUREFIRE-161) VM Forking manifests itself
behind HTTP proxy
Posted by "Ronny Naess (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Updated: (SUREFIRE-109) VM Forking manifests itself behind
HTTP proxy
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] Moved: (SUREFIRE-109) VM Forking manifests itself behind
HTTP proxy
Posted by "Brett Porter (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Porter moved MSUREFIRE-161 to SUREFIRE-109:
-------------------------------------------------
Affects Version/s: (was: 2.3)
2.0 (2.2 plugin)
Fix Version/s: (was: 2.3)
2.3
Component/s: (was: classloading)
plugin
Key: SUREFIRE-109 (was: MSUREFIRE-161)
Project: Maven Surefire (was: Maven 2.x Surefire Plugin)
> 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: plugin
> Affects Versions: 2.0 (2.2 plugin)
> 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