You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Oleg Estekhin (JIRA)" <ji...@codehaus.org> on 2012/08/14 10:49:21 UTC

[jira] (MNG-5326) Class realm created for plugins that use extensions leaks into other plugins

Oleg Estekhin created MNG-5326:
----------------------------------

             Summary: Class realm created for plugins that use extensions leaks into other plugins
                 Key: MNG-5326
                 URL: https://jira.codehaus.org/browse/MNG-5326
             Project: Maven 2 & 3
          Issue Type: Bug
          Components: Class Loading
    Affects Versions: 3.0.4
            Reporter: Oleg Estekhin
         Attachments: extensions-vs-realms.zip

The attached zip contains a test project that displays this issue.

In the terms of the test project, the "clean" plugin will be our demo plugin that suffers from extra class realms, and "jar" and "source" plugins take a role of some other plugins that use extensions.

The build is run with "mvn -X clean" to invoke the "clean" plugin, so "jar" and "source" plugins are not even used during the build.

The "grep Created new class realm"-like part of the build output looks like this:
{quote}
	Line 43: [DEBUG] Created new class realm maven.api
	Line 100: [DEBUG] Created new class realm extension>org.apache.maven.plugins:maven-jar-plugin:2.4
	Line 117: [DEBUG] Created new class realm project>extensions-vs-realms:extensions-vs-realms-1:1.0
	Line 138: [DEBUG] Created new class realm extension>org.apache.maven.plugins:maven-source-plugin:2.1.2
	Line 150: [DEBUG] Created new class realm project>extensions-vs-realms:extensions-vs-realms-2:1.0
	Line 209: [DEBUG] Created new class realm plugin>org.apache.maven.plugins:maven-clean-plugin:2.4.1
	Line 268: [DEBUG] Created new class realm plugin>org.apache.maven.plugins:maven-clean-plugin:2.4.1-1301626664
	Line 327: [DEBUG] Created new class realm plugin>org.apache.maven.plugins:maven-clean-plugin:2.4.1-689777577
{quote}

Maven creates additional class realms to handle extensions in the sub-modules (even if the test project does not actually contain any extensions), and then proceeds to create a normal class realm for the "clean" plugin for the top-level project and two additional class realms for the "clean" plugin for sub-modules.

It means that the "clean" plugin and all of its dependencies will be loaded multiple times using multiple class loaders, which in some special cases could case issues with plugins or their dependencies that use singletons or some other static "single instance in the whole JVM" features. The example of such an issue is https://code.google.com/p/maven-svn-revision-number-plugin/issues/detail?id=16, where the s-r-n plugin uses SvnKit+SqlJet library, and SqlJet library contains a singleton that must be consistent with a singleton inside the JVM code. When s-r-n plugin and its dependencies are loaded multiple times, each class loader hierarchy will have its own SqlJet singleton, and when used concurrently during the parallel build the state of each individual SqlJet singleton will not match the state of the sun.nio.ch.FileChannelImpl$SharedFileLockTable singleton inside the JVM.

The questions and issues to consider:
# If some plugin declares that it wants extensions, but there are actually no extensions declared, could the Maven skip the additional class realm at all?
# In the example the "jar" and "source" plugins are not used in the build, but the Maven still creates all the additional class realms/class loaders. Could it skip this part if it sees that such plugins will not be used?
# In the example the "clean" plugin does not use extensions, but it is reloaded inside class realms that contain extensions. Could all plugins that do not use extensions be used from the normal project's realm, and only plugins that do use extensions be loaded from their special class realms?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira