Hi Todd,

I have the problem that my local test env is not really debuggable (100% CPU "forever" when starting TC).

Anyhow, I have modified the class:

throw new PluginConfigurationException(String.format("Exactly one plugin of class %s must be specified in spring.xml, but there are: " + strings.length,  [...]

And the result is as expected:

16:19:18,937 [Task Engine Worker 2] ERROR com.jivesoftware.base.plugin.PluginManager - Error loading plugin
com.jivesoftware.base.plugin.PluginConfigurationException: Exactly one plugin of class de.dlh.plugins.tac.TermsAndConditionsPlugin must be specified in spring.xml, but there are: 0
at com.jivesoftware.base.plugin.configurators.SpringConfigurator.configure(SpringConfigurator.java:37)
at com.jivesoftware.base.plugin.PluginManagerImpl.loadPlugin(PluginManagerImpl.java:640)
at com.jivesoftware.base.plugin.PluginManagerImpl$1.run(PluginManagerImpl.java:198)
at com.jivesoftware.util.task.TaskEngine$TaskEngineWorker.run(TaskEngine.java:392)

Also see the thread I have referred to, the same has been observed there!

Best regards

Detlev

PS: The DB error I don't have (but I'm using MySQL).

Hi Todd,

> that is very strange

That it seems to be... ;-)

> Are there any other errors related to this plugin outside of this one?

There is a classloading issue later, the real hard problem, see http://www.jivesoftware.com/jivespace/thread/46017 - but in the meantime I fear that that problem is just a consequence from this one here...

Nevertheless, there are no other errors before I am calling the corresponding struts action "checkTermsConds".

I have modified the Springs ClassUtils class, method isAssignable(Class lhsType, Class rhsType), which now prints out "HEY-HO" + some information about the classes and their classloaders. I have attached the full log of a server start (without calling the action; when calling the action, one can see that the interface of the manager class has a different classloader then the implementing class). You'll also see a raised log level for org.springframework.beans.factory.xml.

> its either not matching the name of the class correctly

This can be rules out, as you can see from plugin.xml and spring.xml which had been attached to the original message.

> or the spring.xml in your plugin failed to load

This can be ruled out, too (see attached log), but (also see referred thread): Maybe this depends on some kind of race condition.

Best regards

Detlev

Hi Todd,

One additional info: It seems that already this issue is due to a classloading problem. I have extended the SpringConfiguration class:

if (!(plugin instanceof DummyPlugin)) {

  BeanDefinition beanDef = ctx.getBeanFactory().getBeanDefinition("termsAndConditionsPlugin");
  System.out.println("SPRING_CONFIGURATOR -- " + beanDef.getBeanClassName() + " LOADED BY " + beanDef.getClass().getClassLoader());
  System.out.println("NOW LOOKING FOR -- " + ((Object) (plugin)).getClass().getName() + " LOADED BY " + ((Object) (plugin)).getClass().getClassLoader());
  ...

... and the outcome is, as expected / feared:

HEY-HO: TermsAndConditionsPlugin created by java.net.URLClassLoader@9d9155
SPRING_CONFIGURATOR -- de.dlh.plugins.tac.TermsAndConditionsPlugin LOADED BY WebappClassLoader
  delegate: false
  repositories:
    /WEB-INF/classes/
----------> Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@d70d7a

NOW LOOKING FOR -- de.dlh.plugins.tac.TermsAndConditionsPlugin LOADED BY java.net.URLClassLoader@9d9155
17:57:24,234 [Task Engine Worker 2] ERROR com.jivesoftware.base.plugin.PluginManager - Error loading plugin
com.jivesoftware.base.plugin.PluginConfigurationException: Exactly one plugin of class de.dlh.plugins.tac.TermsAndConditionsPlugin must be specified in spring.xml, but there are: 0
at com.jivesoftware.base.plugin.configurators.SpringConfigurator.configure(SpringConfigurator.java:41)
at com.jivesoftware.base.plugin.PluginManagerImpl.loadPlugin(PluginManagerImpl.java:640)
at com.jivesoftware.base.plugin.PluginManagerImpl$1.run(PluginManagerImpl.java:198)
at com.jivesoftware.util.task.TaskEngine$TaskEngineWorker.run(TaskEngine.java:392)

Best regards

Detlev

PS: At least, fixing this might bring good chances to fix the second one at the same time... :-|

Hi Todd,

Hm, we are running in circles. The "workaround" you provided has been given in the referred thread, too (and a bit more correct).

If you want the constructor to get used, you have to alter the spring.xml to

<bean id="termsAndConditionsPlugin" class="de.dlh.plugins.tac.TermsAndConditionsPlugin">
    <constructor-arg>
        <ref bean="tacManager"/>
    </constructor-arg>
</bean>

instead of using the property tag (otherwise the default constructor gets used).

Nevertheless, I have done this, but the outcome is the same as if I just would delete the class entry from the plugin.xml and use the property tag. When calling the action, I get:

HEY-HO: lhsType = de.dlh.plugins.tac.db.TACManager -- rhsType = de.dlh.plugins.tac.db.TACManagerImpl
HEY-HO: lhsType loaded by: java.net.URLClassLoader@94de98
HEY-HO: rhsType loaded by: java.net.URLClassLoader@134c0a6
HEY-HO: lhsType.isAssignableFrom(rhsType): false

and the system error on the UI and the stack trace (provided in the other thread).

So, I don't think that this kind of workaround really helps in our situation, I fear that the root cause for both issues is a classloading issue, as said, and I hope that tracking this down also brings down the second one.

Best regards

Detlev

Hi Todd,

> OS, Database, App server, JVM version?

WinXP Prof, MySQL 5.1, Tomcat 6.0.18, SUN JDK 1.6.0_13.

Best regards

Detlev