Plugin loading issue again

[Rick Herrick]

I'm having an issue similar to one recently discussed here. Basically I have plugin classes that aren't being loaded. For reference, I've attached my sample projects to this post. I've included jspf jars and a batch file (easily modified to a shell script) for installing the jars into a local Maven repository.

So I have created a PluginService that's getting auto-wired to my controller using Spring annotations. Within the service constructor, I'm creating the PluginManager, then adding plugins. I ran the web application from within Eclipse to start testing. First, I only added plugins from the class path using the ClassURI.CLASSPATH constant. This worked in that it loaded the built-in plugins, but it didn't pick my plugins up.  So I added another call to addPluginsFrom() with the URI set to ClassURI.PLUGIN(PluginAImpl.class). Hooray, that worked! So my code looks like this:

_manager = PluginManagerFactory.createPluginManager();
_manager.addPluginsFrom(ClassURI.CLASSPATH, new OptionReportAfter());
_manager.addPluginsFrom(ClassURI.PLUGIN(PluginAImpl.class), new OptionReportAfter());

When running (again, within Eclipse, or more properly SpringSource Tool Suite), this gives me the following option reports:

>>> Class Report <<<

>>> Object Report <<<
    net.xeoh.plugins.base.impl.PluginInformationImpl@86ecec5 (status:'ACTIVE')
    net.xeoh.plugins.diagnosis.local.impl.DiagnosisImpl@22c8ebd6 (status:'ACTIVE')
    net.xeoh.plugins.base.impl.PluginManagerImpl@54eeabe8 (status:'ACTIVE')
    net.xeoh.plugins.base.impl.PluginConfigurationImpl@15837e8 (status:'ACTIVE')
    net.xeoh.plugins.informationbroker.impl.InformationBrokerImpl@3b947647 (status:'ACTIVE')


>>> Class Report <<<
    org.nrg.xnat.plugins.impl.PluginAImpl (status:'SPAWNED'; dependencies:''; origin:'classpath://UNDEFINED';)

>>> Object Report <<<
    net.xeoh.plugins.base.impl.PluginInformationImpl@86ecec5 (status:'ACTIVE')
    net.xeoh.plugins.diagnosis.local.impl.DiagnosisImpl@22c8ebd6 (status:'ACTIVE')
    net.xeoh.plugins.base.impl.PluginManagerImpl@54eeabe8 (status:'ACTIVE')
    org.nrg.xnat.plugins.impl.PluginAImpl@12d58dfe (status:'ACTIVE')
    net.xeoh.plugins.base.impl.PluginConfigurationImpl@15837e8 (status:'ACTIVE')
    net.xeoh.plugins.informationbroker.impl.InformationBrokerImpl@3b947647 (status:'ACTIVE')

This clarifies why the ClassURI.CLASSPATH URI failed, because apparently my class isn't on the classpath somehow. The jar containing the code is located in the WEB-INF/lib folder and can be referenced and used however you like (e.g. to specify the plugin class explicitly), but somehow that doesn't qualify as being on the classpath. So once I specify it by class, it gets picked up properly and I can reference it with the call in the getPluginA() method in the HelloController class.

Now, we're actually probably going to be generating a list of explicit URIs to jar files in a defined location (similar to how Jenkins loads plugins from $HUDSON_HOME/plugins), so this won't really affect how we do the plugin loading, but I'd like to understand what's going on with JSPF's handling of the classpath to keep from getting bitten by it in the future (e.g. if we provide default plugins in our base configuration that we'd like to have picked up automatically).

Thanks! JSPF looks quite nice thus far, although we're still in the evaluation stage. I'll probably have some more annoying questions down the line :)

[Ralf]

On 19 Mai, 22:45, Rick Herrick <rherr...@gmail.com> wrote:
> _manager = PluginManagerFactory.createPluginManager();
> _manager.addPluginsFrom(ClassURI.CLASSPATH, new OptionReportAfter());
> _manager.addPluginsFrom(ClassURI.PLUGIN(PluginAImpl.class), new OptionReportAfter());

Strange. By definition the second call to addPlugins() should be
superfluous, as PluginAImpl is obviously on the classpath. If it
weren't, the code wouldn't even compile or start to run. Could you
please pass the following props object:


final JSPFProperties props = new JSPFProperties();
props.setProperty(Diagnosis.class, "recording.enabled",
"true");
props.setProperty(Diagnosis.class, "recording.file",
this.masterFilePath + "diagnosis.record");
props.setProperty(Diagnosis.class, "recording.format", "java/
serialization");
props.setProperty(Diagnosis.class,
"analysis.stacktraces.enabled", "true");
props.setProperty(Diagnosis.class,
"analysis.stacktraces.depth", "10000");

to you PluginManagerFactory when creating a PluginManager and then
send me the diagnosis.record file?

> This clarifies why the ClassURI.CLASSPATH URI failed, because apparently my
> class isn't on the classpath somehow. The jar containing the code is located

No, it must be, see above.

> in the WEB-INF/lib folder and can be referenced and used however you like
> (e.g. to specify the plugin class explicitly), but somehow that doesn't
> qualify as being on the classpath. So once I specify it by class, it gets

One thing could be the JSPF's classpath blacklist, but by default it
should be set to something else. You can test that by setting

props.setProperty(PluginManager.class,
"classpath.filter.default.enabled", "false");

or by setting

props.setProperty(PluginManager.class,
"classpath.filter.default.pattern", "pathA;pathB");

(change pathA and B to something else).

> Now, we're actually probably going to be generating a list of explicit URIs
> to jar files in a defined location (similar to how Jenkins loads plugins
> from $HUDSON_HOME/plugins), so this won't really affect how we do the plugin
> loading, but I'd like to understand what's going on with JSPF's handling of
> the classpath to keep from getting bitten by it in the future (e.g. if we

Right now I also don't see any obvious reason for that. If I had to
guess, it might be that

System.getProperty("java.class.path") (JSPF -> ClassPathLocator.java)

somehow does not return all the locations ... mmhm, now that I come to
think about it. Could it be that your web server / application runtime
adds the code where the PluginManager is being created (i.e.,
PluginService) dynamically as well?

In that case, JSPF wouldn't 'see' anything about where it is right
now, and also wouldn't be able to find the other plugins. Then even
the 2nd call to addPlugins() would make sense...

Filed this as Issue #29, investigating.

>  plugins.zip

I've downloaded it and it looks okay, but I don't have the
infrastructure to run it right now, sorry.

[Ralf]

Ah, and could you also paste the output of this line of code please,
just put it where you addPlugins() in JSPF:

String output = System.getProperty("java.class.path");
System.out.println(output);

[Rick Herrick]

Well, it definitely looks as if the classpath is set to something you wouldn't expect!

>>> Class Report <<<

>>> Object Report <<<
    net.xeoh.plugins.informationbroker.impl.InformationBrokerImpl@477baf4 (status:'ACTIVE')
    net.xeoh.plugins.base.impl.PluginManagerImpl@1f4649ed (status:'ACTIVE')
    net.xeoh.plugins.diagnosis.local.impl.DiagnosisImpl@15364ee5 (status:'ACTIVE')
    net.xeoh.plugins.base.impl.PluginConfigurationImpl@3f9f76a5 (status:'ACTIVE')
    net.xeoh.plugins.base.impl.PluginInformationImpl@23f2bc83 (status:'ACTIVE')

>>> Class Report <<<
    org.nrg.xnat.plugins.impl.PluginAImpl (status:'SPAWNED'; dependencies:''; origin:'classpath://UNDEFINED';)

>>> Object Report <<<

    org.nrg.xnat.plugins.impl.PluginAImpl@73fce83e (status:'ACTIVE')
    net.xeoh.plugins.informationbroker.impl.InformationBrokerImpl@477baf4 (status:'ACTIVE')
    net.xeoh.plugins.base.impl.PluginManagerImpl@1f4649ed (status:'ACTIVE')
    net.xeoh.plugins.diagnosis.local.impl.DiagnosisImpl@15364ee5 (status:'ACTIVE')
    net.xeoh.plugins.base.impl.PluginConfigurationImpl@3f9f76a5 (status:'ACTIVE')
    net.xeoh.plugins.base.impl.PluginInformationImpl@23f2bc83 (status:'ACTIVE')

java.class.path: D:\Servers\Tomcat-6.0\bin\bootstrap.jar;C:\jdk1.6\lib\tools.jar

And that's running Tomcat out of Eclipse. If I drop the war file up in Tomcat and run that stand-alone, I get:

java.class.path: D:\Servers\Tomcat-6.0\bin\bootstrap.jar

This appears to be inherent to the environment (Tomcat 6, obviously), since a real simple Web app, one JSP page and nothing else, gives me the same result.

It looks like all of the class loader management in JSPF is handled through the ClassPathManager class. Is it possible (or wise) to get in and work with the loaders there? Or is that all done indirectly through the addFilesFrom() calls?

[djwe...@gmail.com]

I am having the exact same issue as Rick, except with JBoss.  I am able to add a plugin when I reference it explicitly (using ClassURI.PLUGIN()) but when I use ClassURI.CLASSPATH() it doesn't find my plugin.

Output from:

String output = System.getProperty("java.class.path"); 
System.out.println(output);

Prints: classpath: /Applications/jboss-as-7.1.1.Final/jboss-modules.jar

Nothing from my application's classpath is listed.  Does anyone know the solution to this problem?