Thursday, April 30, 2009

Jopr 2.2 released



You may have seen yesterday and the day before that JBoss Operations Network 2.2 has been released. And you probably also know that Jopr is the upstream project for JBoss ON.

So we are pleased to announce the availability of Jopr 2.2.






You can download Jopr 2.2 from Sourceforge.

Note that the distro does not have a separate agent download, but the agent is included in the server. Set up the server, log in and then in the top menu you will find Admin->Agents->Download

Otherwise have a look at the install docs in our wiki.

Joe Marques has a longer list of new features in his respective blog post.

Wednesday, April 29, 2009

JBoss ON 2.2 has been released

Greg Hinkle already wrote it: JBossON 2.2 has been released.
This has been a big release for us - with arounds six month of work.

Some of you may already had a peek at the Jopr 2.2 beta and my know about some of the new stuff.



Changes were (in addition to hundreds of small enhancements and bugfixes):

* UI - Completely updated (and mostly rewritten from Struts to JSF), AJAX based UI with tree views, search and common menu system
* Clusters - Cluster oriented tree views with group-wise configuration management and monitoring
* Security - Improved DynaGroups queries and new support for recursive compatible groups simplifies access control
* Monitoring - Configuration change detection, auditing and historical review
* Agent auto upgrade - Agents automatically update themselves when new servers are installed
* Subsystem views - Pages that e.g. show alert info over all existing resources
* Much better IE support
* Speed improvements
* Automatic recalculatin of DynaGroups
* Plugin skeleton generator


More information about JBossON 2.2 can be found at http://www.jboss.com/products/jbosson

Wednesday, April 22, 2009

I love the Standalone container in Jopr (updated)


I am just working on a plugin when I have some spare cycles (I will tell you which one in a few days :-)

To test the plugin I am using the Standalone Container where I have deployed my plugin, the JMX and the platform plugin.
So when I have compiled a new version of the plugin I just copy it over and start the standalone container:

snert:rhq-agent hrupp$ bin/standalone.sh

Listening for transport dt_socket at address: 8788



Starting the plugin container.

Loading plugins

...Loaded plugin: Platforms

...Loaded plugin: JMX

...Loaded plugin: MyNewOne



Ready.

[0]:0 >


This takes 3 seconds and then I am ready to discover resources:

[0]:0 > disc s

Discovery took: 2269ms

[Resource[id=-3, type=Secret, key=service:jmx:rmi://127.0.0.1/jndi/rmi://127.0.0.1:1090/jmxconnector, name=Secret, parent=snert]]

[1]:0 >


Now I can test if my invokeOperation() method from the OperationFacet works:

[2]:-0 > set res -3

[3]:-3 > invoke getProperty name=test

[PropertySimple[id=0, name=result, value=null, override=null]]


So set the resource id to the resource I want to work with and then invoke the getProperty operation with parameter name and value test. The Operation then returned null, as the underlying resource does not know this specific value.

This all took around 10 seconds now for a round trip - you can't really do faster testing :-)

When I want to repeat those steps with an updated version of the plugin, I can save my work:

[4]:-3 > !w /tmp/foo

This creates a file and saves the commands given in it. The name of the file can later be given on the command line to just run the action as a script without any need to manually type in the commands.

There is currently one caveat: Resource ids will change in each startup so the "set" command in step 2 above will not work exactly like this.

[UPDATE]


I will work on adding variables to the find command in the standalone container which can then be passed to set -- if you want to help out contact me.


What you can do is to use $r as 2nd parameter to set after finding a single resource:

[5]:0 > find r *myFooBar*

-12: MyFooBar ( Resource[id=-3, ... )

[6]:0 > set r $r

[7]:-12 >



With this trick it is now possible to just run the container with the saved file as input again and again

$snert bin/standalone.sh /tmp/foo

Monday, April 20, 2009

RHQ and Jopr plugins: What about <T> ?

When writing a Plugin for RHQ, JBoss ON and Jopr (or for completeness: Embedded Jopr, you will run into Generic types for ResourceComponent and ResourceDiscoveryComponent. And I am sure you have often wondered what the T in ResourceComponent<T> should be.

The following diagram tries to help here. We have two ResourceTypes that from a Parent-Child relationship e.g. a Database and a DatabaseTable.

If you don't know what parent you will run in, you can just leave the generic bit away, as in ParentDiscovery and Parent in the diagram. This is usually the case for ResourceTypes of the Server category that live in their own plugin. One could also use the platform component as parent if its clear that the plugin will only run as a child of the platform, but never e.g. within another resource like a JBossAS.



InheritanceDiagram.png


Children of this server Parent will set the T to the parent component. This allows them to e.g. access the parent ResourceContext.

For examples of all this, check the Jopr source code, which contains many examples.

Friday, April 17, 2009

♫ I'm running in the rain ... ♫

Today it was raining, but I had the urge to go out for a run, so I went out nevertheless. Normally I am more a like a sissy in that area though.

But after around 1km I felt warm enough so that it did not feel uncomfortable anymore and later on it did not even feel bad being splashed by a car driving through a puddle. And this is how I looked when I was coming home:

DSC00039.JPG


But hey, it felt great !

And the best: my Adidas (Supernova) shoes stayed dry inside. No wet feet - I just love those.

( The very best was actually that my ankle did not hurt )

Jopr/RHQ plugin generator updated

The plugin generator has been updated for the plugin lifecycle listener. I have uploaded a new version to the description page on the RHQ wiki.
So you can grab the standalone jar file from there without the need to download the RHQ source and compile it from scratch -- which would not be hard actually:


$ cd $RHQ/modules/helpers/pluginGen

$ mvn install


You can find the resulting rhq-pluginGen*-jar-with-dependencies.jar in target/ then.

Sunday, April 05, 2009

List of Jopr / RHQ resources


Just as a FYI:

Mazz has, while answering a forums post made a nice list of resources
related to Jopr and RHQ.

Check out the post at the Jopr user forum.