META-INF manifest.mf rhq-serverplugin.xml // the perpective descriptor) app1.war // optional apps .. appN.war classes // optional classes to support dynamic filtering (this is under consideration)
Perspectives will be implemented as server-side plugins. As such the perspective will deploy as a JAR as required for a well formed SSP. Deployed as such the db persistence, version update and HA synchronizing will be handled by the Master SSP container (SSPC).
There will also be a Perspective SPC (PSPC) coupled with a Perspective SP Manager (PSPM) to for perspective-specific lifecycle event handling. The PSPM will handle load and unload of the perspective, handling the deploy or undeploy of associated webapps. Note that the PSPC and PSPM are RHQ code, part of the Perspective subsystem. They handle all deployed perspectives and are not provided by a perspective itself.
Currently there is no identified need for a SP listener, or for perspective Configuration. This could change as development continues.
The SSP JAR structure is simple, requiring only a server plugin descriptor. The perpective plugin descriptor imports and end extends the base SSP descriptor XSD. Additionally, the SSP JAR can contain any other artifacts required for deployment. For perspectives this includes optional WAR files that, when deployed, satisfy the request URLs defined for the perspective.
The structure looks like:
META-INF manifest.mf rhq-serverplugin.xml // the perpective descriptor) app1.war // optional apps .. appN.war classes // optional classes to support dynamic filtering (this is under consideration)
Major points:
Every perspective defines a single perspective descriptor. This is an XML file describing the perspective, its extension points, etc.
The file is named as defined by the SSP requirements, currently rhq-serverplugin.xml.
Perspectives are delivered as a JAR file, named as defined by the SSP requirements, probably perspective-name-VERSION.jar.
Perspectives JARs are deployed as defined by the SSP requirements, currently ../deploy/rhq.ear/rhq-serverplugins
Analogous to agent plugins, perspectives are stored in the database and automatically distributed to HA Servers. Version handling is similar and deployment is live using a recurring server job.
The perspective JAR file can optionally include one or more WAR files supporting the urls defined in the perspective descriptor. URLs referring to these apps will be relative. (e.g. /myperspective/foo).
The apps will be managed using the AS MainDeployer Mbean. They will be deployed on plugin load and undeployed on plugin unload. Other lifecycle events should be able to be supported as needed.
The perspective JAR file can optionally include Java classes that cvan resolve dynamic extension point activation/filtering requests.
This is an active design topic
It is hoped that, unlike agent plugins, the perspective descriptor will not require db stored meta-data. The descriptor will be managed in memory by RHQ. This prevents meta-data update issues. But, it needs to be proven that necessary extension point activation (filter processing) can be performant without utilizing db-level querying. If not then the Perspective Handler will be responsible for managing the descriptor/db synchronization.
For applications referred to from the perspective that are not java, or not deployed in the way above, the urls will need to be fully qualified.
While working towards production perspectives we'll be deploying the Sample Perspective in a Dev build environment (-Pdev). It will live under rhq/etc/samples/perspectives/sample-perspective:
It is built and deployed along with the other server plugins (e.g. content plugins):
The Sample Perspective will increasingly utilize the defined extension points as they are supported in the code. As of this update this includes:
Perspective Deployment
rhq-sample-perspective.war deployed
mock extension point: ResourceTab:Custom
the war provides content but the tab is hard-wired (i.e. not defined in the perspective descriptor)
The Sample Perspective deployment JAR conforms to the RHQ Server Plugin model and has the following structure:
The structure looks like:
META-INF manifest.mf rhq-serverplugin.xml // the perpective descriptor) rhq-sample-perspective.war // optional app (supports Custon Tag)
At RHQ Server startup the perspective will be loaded. The following should be in the console log:
And when navigating to a Resource in the GUI the Custom Tab should look like this:
Similarly, once could visit the sample app via http://<host>:7080/rhq-sample-perspective