Rationale
We need to incorporate other GUIs in our gui.
E.g. jBPM offers a console that allows to do fancy modifications to processes.
When we'd detect a jBPM node, we should be able to right click on it and e.g open a new window with the
jBPM console in it. The open window would then directly navigate to the right item in the jBPM console
We should also allow calling the other way around, as consoles like the jBPM one will and should not e.g.
monitor JBossAS servers or Linux hosts they are running on.
Implementation idea for the interface to other developers
We add the following to the plugin descriptor within the respective p/s/s section
<handOff>
<top> <!-- information for the table above the MICOA tabs -->
<baseUrl>http://localhost:7080/jmx-console</baseUrl> <!-- base url -->
<title>JMX Console</title> <!-- title to show instead of the 'naked' link -->
<element> <!-- one element of the url ( &key=value ) can be repeated multiple times -->
<key>xyz</key>
<value>%r</value>
</element>
<element>
<key>abc</key>
<value>%t</value>
</element>
</top>
<menu> <!-- General menu item to add in the tree -->
<baseUrl>...</baseUrl>
<title/>
<icon>jBPM.png</icon> <!-- an icon that appears in the tree -- must be packaged in the plugin -->
</menu>
<contextMenu> <!-- Menu specific to a tree entry of the specific type -->
<baseUrl>http://localhost:7080/jmx-console</baseUrl>
<title>JMX Console</title>
<element>
<key>xyz</key>
<value>%r</value>
</element>
<element>
<key>abc</key>
<value>%t</value>
</element>
</contextMenu>
</handOff>
The following mock UI shows the three anchor points.
Of course the jBPM TOP item and the one in the contextMenu would only show for relevant resource types and not
for a CPU resource I used to do the mock.
Interpolated strings
The previous example shows the use of interpolations (%x) - we should at least support
-
%r - resource Id
-
%t - resource type
-
%n - resource name
Work areas
Server
Domain
The new information needs to be added to the domain objects. As they are specific to a certain
resource type, the resource type table needs to be changed - the optional stuff should possibly go
into a new table
Client-api
The xml schema for rhq-plugin.xsd needs to be adjusted to support the new optional elements
Plugin deployer
The plugin deployer needs to pull the new information out of the plugin descriptor and put this in
the domain as long as provided images.
GUI
The nav tree and the top element needs to pull the respective information from the domain and show it for
resources of the appropriate type
Agent
We must make sure that agents don't freak out when the new optional element in the plugin descriptor are passed in. It might be as simple as just passing them the new rhq-plugin.xsd and linking against a new version of client-api.