Red Hat Bugzilla – Full Text Bug Listing
|Summary:||RfE: Allow to deploy descriptor-only plugins|
|Product:||[Other] RHQ Project||Reporter:||Heiko W. Rupp <hrupp>|
|Component:||Plugins||Assignee:||Heiko W. Rupp <hrupp>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike Foley <mfoley>|
|Version:||4.2||CC:||ccrouch, hrupp, mazz, rsoares|
|Target Release:||RHQ 4.5.0|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-09-01 06:10:41 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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  can be useful in this case.  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.