Bug 535717 (RHQ-2384)

Tagged as 1.3 for triage

https://jira.jboss.org/jira/browse/SOA-1461 fixes this issue for the SOA-P plugin but I would still like to know how we regressed between 2.2 and 2.3

This issue should be closed as "Works as Intended".

Please read this:

http://jopr.org/confluence/display/RHQ/AMPS-Plugin+Extensions

and the design page which I created before and during the new classloader implementation stuff  so this shouldn't be a surprise :)

http://jopr.org/confluence/display/RHQ/Plugin+Dependencies+and+Class+Loaders

Note where it specifically says in http://jopr.org/confluence/display/RHQ/AMPS-Plugin+Extensions#AMPS-PluginExtensions-%3Cdepends%3E :

"There is a <depends> element directly under the <plugin> element that defines one or more parent plugins that the plugin depends on. When using <depends>, you are specifying a "required dependency". This means the plugin will not deploy successfully, unless all <depends> plugins are also successfully deployed."

If you read further, you will find that now we have what we call "optional dependencies" which is what you want:

"If you are only depending on another plugin for its resource types to inject or embed, you usually do not have to specify <depends> on that other plugin. You normally will specify <depends> for one of two reasons:

   1. Your plugin needs access to another plugin's classes
   2. You want to require that your plugin is only ever deployed when another plugin is also deployed.
"

If you do not want your plugin to blow up during deployment if a plugin is missing, this simply means your plugin has an OPTIONAL dependency - and therefore should NOT have a <depends> tag. Just take it out and you've implicitly defined an "optional dependency" which is what you want. Yes, <depends> changed its semantics - again, this should not be a surprise as this was mentioned early on in the development cycle of the new classloader stuff.

Lowering to minor with the intention of closing this - leaving open to continue discussion if it is warranted.

Understood mazz. This is still a change in behaviour that could mean your plugin which works fine in 2.2 blows up 2.3. We need to doc it in the release notes.

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2384

Blocking release notes and plugin guide trackers.

This is a 2.3 release notes item

I've added this to the known issues section for the 2.3 release notes:
http://www.redhat.com/docs/en-US/JBoss_ON/2.3/html-single/Release_Notes/index.html#Known-Issues-with-this-release

The text (which is basically taken from comment #3):

4. Known Issues with This Release

<depends> Tag Referencing Non-existent Plug-in Causes Plug-in Deployment to Fail

The new classloader implementation in JBoss ON 2.3 introduced other changes to the way that JBoss ON handles plug-ins and dependencies. This may require you to change your current JBoss ON plug-ins before upgrading to version 2.3, or plug-in deployment could fail. 

Plug-in definitions can have a <depends> element directly under the <plugin> element. In JBoss ON 2.3, this <depends> element defines a parent plug-in that the plug-in requires to run. In other words, this defines a required dependency. Every single plug-in specified in a <depends> element has to be successfully loaded and deployed. Broken or non-existent required dependencies cause the plug-in to fail to load.

In previous versions of JBoss ON, the <depends> element could specify an optional dependency. So, specifying a non-existent plug-in wouldn't cause the plug-in deployment to fail because the dependency wasn't treated as if it was required.

If the dependency is only necessary for another plug-in to inject or embed its resource types, it is no longer necessary to use the <depends> element in the plug-in definition. Optional plug-in dependencies can be referenced using elements like <server>, <service>, or <runs-inside>.

A <depends> element is only used in one of two situations:

    * The plug-in must access to another plug-in's classes.
    * The plug-in should only ever be deployed if the other, referenced plug-in is deployed. 

This change is noted in Bugzilla #535717. 

+++++++++++++++++++++++

I'm changing the status to ON_QA for Corey to review.

Looks good.  QA Verified.

Mass-closure of verified bugs against JON.