Le mardi 08 avril 2008, Jason van Zyl a écrit : > Whatever operations are performed on our side that switches the > classloader should switch it back. > > The analysis below doesn't really help us identify where this is > happening, but Herve can probably take a look. It might be in the task > code, or in Maven itself. the switch is done in org.codehaus.plexus.org.codehaus.plexus#initializeClassWorlds(), called by org.codehaus.plexus.embed#start( ClassWorld ) The API does change the classloader without storing the previous one, and there is no API to switch it back.
For Maven Ant Tasks, it should be easy to fix the problem: please open a Jira issue, and I'll fix it before Maven Ant Tasks 2.0.9 which should be released in a week or 2 AFAIK, the problem exists in embedder too, or I missed the code in embedder that switches the classloader back... Hervé > > On 7-Apr-08, at 11:22 PM, Thomas Tardy wrote: > > Hello, > > > > I'm struggeling with some problems using the Maven ant tasks in the CI > > environment with IBM Jazz. There are some ant tasks for IBM Jazz which > > are handling the connection between the build engine and the Jazz > > server. These Jazz ant tasks are working well as long as I haven't > > used the Maven ant task in the build script. One of the Jazz guys > > analyzed the problem as follows: > > > > [quote] > > I was able to get some understanding of this problem. Maven is > > switching out the context class loader on the main Ant thread when > > their task is invoked. Before the Maven task runs when everything > > works properly...the main ant thread has a class loader of... > > > > classLoader Launcher$AppClassLoader (id=113) > > [EMAIL PROTECTED] > > > > After the Maven task runs the class loader is now... > > > > classLoader RealmClassLoader (id=166) > > [EMAIL PROTECTED] > > > > EMF can no longer find the appropriate factory as it delegates to the > > class loader to find the EMF package. The NPE is then thrown as it > > attempts to use the null factory to get the item type in > > WebServicesSAXXHandler while marshalling the request to the server. I > > hacked into our task a trap of the class loader before the Maven call > > and then set it back the next time our task executed. Everything > > worked fine again. It seems ridiculous that Maven is switching the > > class loader for the main ant thread when their task executes...at the > > very least if this insanity is necessary they should be switching it > > back. > > > > It appears you can work around this problem by making your pom call > > into Maven before you call any of our ant tasks. We then appear to > > get initially loaded into their class loader correctly and everything > > works ok. > > [/quote] > > > > Why is the Maven ant task switching the class loader for the main ant > > thread? Is this a bug or works as designed? > > > > Thanks for your feedback! > > > > Regards, > > Thomas > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > In short, man creates for himself a new religion of a rational > and technical order to justify his work and to be justified in it. > > -- Jacques Ellul, The Technological Society > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
