maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephane Nicoll" <stephane.nic...@gmail.com>
Subject Re: MNG-2571 - weird exception using the embedder
Date Mon, 02 Oct 2006 13:28:20 GMT
Kenney,

On 10/2/06, Kenney Westerhof <kenney@apache.org> wrote:
> Hi, Stephane,
>
> I'm trying to reproduce this

Thanks ;-)

> but I'm having trouble. First, the
> dependency on maven-plugin-testing-harness is missing. Secondly,
> even though the localRepoDir is correct, the ejb-sample-one and -two
> can't be found.

You're righy. I had also those problems with the localRepoDir and they
went away when I added a specific dependency in my POM. I will do a
quick check this evening and will commit the necesseray dependencies.

>
> Anyway, the problem is with the setClassLoader(). That one already contains
> the EjbModule (and EarMojo) classes since they're in src/main/java. So they're also available
to plexus.
>
> The embedder tries to configure another EarMojo in a new plugin classloader, and
> instantiates the EjbModule from the embedder classloader, not from the plugin classloader.
> That's because the plugin classloader delegates to the parent (the embedder classloader),
> and finds an instance of the field class there.

That sounds way overcomplicated to me but thanks for the explanation.

>
> Solution: use an isolated classloader where the mojo code itself is NOT part of the embedder.
> For instance, by using the maven-it-plugin, (or maven-invoker?) or by constructing a
new classloader with the
> embedder archive and it's dependencies manually.

Mmmm. I must say that I am bit lost with all those testing techniques.
Is there *one* tested recommendation for testing Mojos around?

Any pointer / examples for your suggestions above?

Thanks a lot!

St├ęphane

>
> -- Kenney
>
> Stephane Nicoll wrote:
> > On 10/1/06, Stephane Nicoll <stephane.nicoll@gmail.com> wrote:
> >> On 10/1/06, David Jencks <david_jencks@yahoo.com> wrote:
> >> >
> >> >
> >> > The classes are in different classloaders.  Hopefully the
> >> > classloaders' toString() will give you enough info about which ones
> >> > they are if you add that to the debugging.
> >>
> >> You're right. The interface and the actual implementation are in
> >> different classloaders.
> >
> > More specifically:
> >
> > Classloader...
> > Current thread
> > classloader[org.codehaus.classworlds.RealmClassLoader@b60b93]
> > type.getComponentType classloader[sun.misc.Launcher$AppClassLoader@e80a59]
> > values(0). classloader[org.codehaus.classworlds.RealmClassLoader@5e13ad]
> > The component Type is[ interface org.apache.maven.plugin.ear.EarModule]
> > The values elements are the following
> > Object class[org.apache.maven.plugin.ear.EjbModule] - is NOT
> > assignable to[interface org.apache.maven.plugin.ear.EarModule] !!!
> >
> > s/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Un chewing-gum? Non merci, jamais pour parler.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message