[ http://jira.codehaus.org/browse/MNG-908?page=all ]
     
Kenney Westerhof closed MNG-908:
--------------------------------

     Assign To: Kenney Westerhof
    Resolution: Fixed

Fixed in svn revision 290040.
Tested with a custom Mojo and a dependency that has a resource.

> Context class loader references incorrect realm during plugin execution
> -----------------------------------------------------------------------
>
>          Key: MNG-908
>          URL: http://jira.codehaus.org/browse/MNG-908
>      Project: Maven 2
>         Type: Bug
>     Versions: 2.0-beta-1
>  Environment: WinXP SP2, Java 1.4.2, Maven-2.0-beta-1
>     Reporter: John Fallows
>     Assignee: Kenney Westerhof
>      Fix For: 2.0-beta-2

>
>
> John Fallows wrote:
> I am currently developing a custom maven2 plugin that needs to parse
> some xml files (using xmlbeans).  Therefore I used the m2 xmlbeans
> plugin at mojo.codehaus.org to generate the Java code for 3 different
> schema namespaces.
> Unit tests within the plugin verify that this code has been generated
> correctly and works as expected.
> However, when another m2 project attempts to use the custom plugin,
> not all the parsed xml data structures are strongly typed Java
> Objects.  Instead, some are just simple XmlObjects, as though no type
> information was generated.
> It seems as though some of the type information cannot be located by
> the xmlbeans runtime when executed through a maven2 plugin.  Could the
> classworlds classloader be somehow preventing xmlbeans from seeing all
> the type information?
> John Fallows wrote:
> Ok, so i've done some more digging and it appears to be a classloader
> problem in M2 rather than anything xmlbeans-specific.
> The reason that some of the xmlbeans type information is not available
> is that a call to
> contextClassLoader.getResourceAsStream("some-generated-xmlbeans-resource")
> is returning null when it should be returning non-null.
> However, the class loader of the CustomMojo.class itself does return a
> non-null stream as desired.
> So, I have worked around this by doing the following in CustomMojo:
>  public void execute() throws MojoExecutionException
>  {
>    ClassLoader ccl = Thread.currentThread().getContextClassLoader();
>    try
>    {
>      
> Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
>      ... other Mojo code that calls XmlBeans here ...
>    }
>    finally
>    {
>      Thread.currentThread().setContextClassLoader(ccl);
>    }
>  }
> Is this something that could be managed by the M2 runtime instead?

-- 
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


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to