Bug 741682 - RfE: Allow to deploy descriptor-only plugins
RfE: Allow to deploy descriptor-only plugins
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
4.2
Unspecified Unspecified
medium Severity medium (vote)
: ---
: RHQ 4.5.0
Assigned To: Heiko W. Rupp
Mike Foley
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-27 11:05 EDT by Heiko W. Rupp
Modified: 2013-09-01 06:10 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-01 06:10:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Possible patch (11.54 KB, patch)
2012-07-11 11:49 EDT, Heiko W. Rupp
no flags Details | Diff
Proposed patch (7.45 KB, patch)
2012-07-11 16:16 EDT, Heiko W. Rupp
no flags Details | Diff

  None (edit)
Description Heiko W. Rupp 2011-09-27 11:05:08 EDT
The custom jmx plugin is a plugin that basically only consists of the plugin descriptor and which uses all the methods from the jmx-plugin to do its work.
Unfortunately this descriptor still needs to be packaged with in the plugin jar - even if no classes are deployed alongside, which is a hassle for quick plugin deployment.

It should be possible to deploy files that match the pattern "*-rhq-plugin.xml" as plugins, where the file is just a plugin descriptor which refers to exsiting plugins like the jmx one (or perhaps in the future to the script one or jruby-script or such.

Within the code on the server side, the plugin scanner would need to be modified to recognize those files, as well as the plugin deploy code to skip the unzip step and directly go the descriptor parsing (which would probably need to be changed slightly to understand *-rhq-plugin.xml names).
Changes on the plugin container side should be very similar.
Comment 1 John Mazzitelli 2011-09-27 11:10:10 EDT
easiest thing we could do right now is to package the .xml ourselves at runtime and deploy it as a jar. So if you copy a rhq-plugin.xml file to the /plugins directory, we grab it and before we put it in the real rhq.ear/plugins directory, we first zip it up and then copy it over. That's all we'd need to do - because from there on its just a normal plugin jar and no additional/extra processing or code changes are needed. This would be a localized enhancement solely in the plugin detector code - the thing that looks for files in the dropbox /plugins directory and the code that copies it over. Probably less than a day's worth of work to do this.
Comment 2 Heiko W. Rupp 2011-09-27 11:18:58 EDT
So you mean foo-rhq-plugin.xml becomes foo.jar with the .xml file pushed inside.
I agree that sounds very viable.
Would that also work via the UI plugins page? I think if a user has written such a *-rhq-plugin.xm file based plugin, he would want to deploy that thing later to production via the more official means.
Comment 3 John Mazzitelli 2011-09-27 11:44:22 EDT
(In reply to comment #2)
> So you mean foo-rhq-plugin.xml becomes foo.jar with the .xml file pushed
> inside.

If you want to restrict the name of the file to requiring "-rhq-plugin.xml", yes you could do that. I was envisioning just taking whatever file name they give it and replace .xml to .jar. For example, "foo.xml" would be my descriptor which would result in "foo.jar", inside of that jar would be a rhq-plugin.xml file that has the same content as the original foo.xml.

> Would that also work via the UI plugins page? I think if a user has written
> such a *-rhq-plugin.xm file based plugin, he would want to deploy that thing
> later to production via the more official means.

I'm not sure if we restrict the file upload to only accept .jar files or not - its possible this will "just work" if we don't care what file extension we accept during the file upload. Taht would be simple to test and probably simple to workaround if we do only accept .jar files.
Comment 4 Ian Springer 2011-09-27 12:01:02 EDT
Note, Hyperic HQ supports this.

http://support.hyperic.com/display/DOC/Plugin+XML+Descriptor
Comment 5 Heiko W. Rupp 2011-09-27 16:07:28 EDT
(In reply to comment #3)
> If you want to restrict the name of the file to requiring "-rhq-plugin.xml",
> yes you could do that. I was envisioning just taking whatever file name they

Yes I would require that, as this way it 
a) is more clear what can be deployed
b) prevents users to deploy 2* rhq-plugin.xml for different plugins and be astonished that one of those get overwritten by the other. Here it is a bit clearer that the user needs to give it a proper name.
Comment 6 Rafael Soares (Tuelho) 2011-10-22 19:41:37 EDT
Hi.

Maybe the JBoss Shrinkwrap project [1] can be useful in this case.

[1] http://www.jboss.org/shrinkwrap
Comment 7 Heiko W. Rupp 2012-07-11 11:49:03 EDT
Created attachment 597612 [details]
Possible patch

This patch allows to deploy *-rhq-plugin.xml files as plugin descriptor.
Such a plugin will register fine on the server and will need discovery and component classes from other plugins (e.g. abstract base ones).
Comment 8 Heiko W. Rupp 2012-07-11 16:16:45 EDT
Created attachment 597664 [details]
Proposed patch

Updated patch after having discussed this with Mazz.

We will now just wrap such a plugin descriptor into a jar and put this back into the plugins directory from which the plugin scanner will pick it up and do the normal processing.
Comment 9 Heiko W. Rupp 2012-07-12 04:36:08 EDT
master 1656f7c935fe1b

Such jar-less plugins need to be named *-rhq-plugin.xml 

See also http://pilhuhn.blogspot.de/2012/07/jar-less-plugins-for-rhq.html
Comment 10 Heiko W. Rupp 2013-09-01 06:10:41 EDT
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.

Note You need to log in before you can comment on or make changes to this bug.