Wednesday, December 30, 2009

Laufen 2009 / 2010 (German)

Das Jahr neigt sich dem Ende zu; Zeit für einen Jahresrückblick: ich habe beide gesteckten Laufziele gut geschafft:

- Stuttgart-Lauf ankommen. Ich habe das Ziel dann zweimal hochgesetzt. Erst auf unter 2:30h und dann auf unter 2:15h. Letztlich war es dann besser :-)

- Mehr als 750km laufen - das habe ich mit 792km auch gut hinbekommen - wenngleich ich im Dezember nochmals richtig Gas geben musste

Distanz792,23 km
Distanz pro Einheit Ø10,56 km
Pace Ø5:55 min/km
Geschwindigkeit Ø10,14 km/h
Fitness46 (37-45)
Puls Ø / Max159/191

Bester Monat war der Dezember mit 135km

Läufe an "exotischen" Plätzen:

Ziele für 2010

- Stuttgart-Lauf schneller als 2009 (also unter 1:59:04) - wenn das Wetter mitspielt und ich nicht krank bin

- 900 Laufkilometer

Monday, December 21, 2009

RHQ / Jopr tab sweep

This post is to gather a few of the recent developments around RHQ and Jopr

Just in case you have missed it: RHQ 1.4.0.B01 is out - this build contains the Jopr plugins and thus is the successor of the Jopr-server builds that you have seen before.

Mailing lists:

We have opened two mailing lists for RHQ where we expect to bundle the email activities in the future:

  • rhq-users: for user questions around RHQ (including the Jopr plugins

  • rhq-devel: for developing with and on RHQ


Galder Zamarenno from Infinispan has created a video showing a three-node Infinispan cluster being monitored. It demonstrates graphical measurements, and non-graphical information of running Infinispan instances, addition or removal of monitored metrics and finally, execution of management operations on a Infinispan instance.

Mazz has created a demo on how to use the new server side plugins to periodically create reports on the server.

Alert senders:

Alert notifications can now be processed by plugins. This means that it is finally possible to easily write own notification schemes to forward alerts to various devices. Two posts show how to write such a sender (Part 1 & Part 2).

Agent plugins:

A new agent plugin allows to use script in Ruby and JavaScript to do monitoring. This allows to easily monitor resources via dynamic scripting languages without writing Java code.

Tuesday, December 15, 2009

How to write an alert sender plugin for RHQ/Jopr (Part 2)

Now that we have seen the "theoretical side" of writing an alert sender, lets just start and code one up.

First grab RHQ from GIT and then change into

  • Run this little script:

    mkdir alert-url
    cd alert-url
    mkdir -p src/main/java/org/rhq/enterprise/server/plugins/alertUrl
    mkdir -p src/main/resources/META-INF

  • copy over the pom.xml from alert-email and change email to url in it:

    cp ../alert-email/pom.xml pom.xml,1
    sed -e 's/email/url/' < pom.xml,1 > pom.xml

  • Lets edit the plugin descriptor

    vi src/main/resources/META-INF/rhq-serverplugin.xml

    description="Alert sender plugin"

    This is just the generic header. Now lets set the target host name on the server-wide preferences and

    <c:simple-property name="hostName"
    default="localhost" />

    Now the name of the sender and its alert sender class

    <!-- Class that does the actual sending -->

    And now finally the Information that is specific to an alert definition. Lets just set the port here for demonstation purposes.

    <c:simple-property name="port" type="integer"/>

  • Now lets implement the Java sender class

    $ cd src/main/java/org/rhq/enterprise/server/plugins/alertUrl
    $ vi

    package org.rhq.enterprise.server.plugins.alertUrl;
    import org.apache.commons.logging.Log;
    import org.apache.commons.logging.LogFactory;
    import org.rhq.core.domain.alert.Alert;
    import org.rhq.enterprise.server.alert.AlertManagerLocal;
    import org.rhq.enterprise.server.plugin.pc.alert.AlertSender;
    import org.rhq.enterprise.server.plugin.pc.alert.ResultState;
    import org.rhq.enterprise.server.plugin.pc.alert.SenderResult;
    import org.rhq.enterprise.server.util.LookupUtil;
    import org.rhq.enterprise.server.xmlschema.generated.serverplugin.perspective.ResourceTaskElement;
    public class UrlSender extends AlertSender{
    public SenderResult send(Alert alert) {

    So this was just the bolier plate code - now lets get the work done by first getting our data that the user entered in the UI

    String hostname = preferences.getSimpleValue("hostname","localhost");
    String portS = alertParameters.getSimpleValue("port","80");

    Then construct an URL and URL connection

    HttpURLConnection conn = null;
    try {
    URL url = new URL("http://" + hostname + ":" + portS);
    conn = (HttpURLConnection) url.openConnection();
    OutputStream out = conn.getOutputStream();

    Then we get the message together - you see, you can even call into the EJB layer to get things done - and send it off.
    AlertManagerLocal alertManager = LookupUtil.getAlertManager();
    StringBuilder b = new StringBuilder("Alert: '");
    b.append("' (");
    b.append("): ");
    } catch (Exception e) {
    return new SenderResult(ResultState.FAILURE,"Sending failed " + e.getMessage());
    finally {
    if (conn!=null)
    return new SenderResult(ResultState.SUCCESS,"Sending to " + hostname + ":" + portS + " worked");

    After this was done, we return our operation result in a new SenderResult object - that's all.

    Now just change back to the root directory (the one with the pom.xml file) and fire "mvn install". This leaves you with a jar archive in target/ that you can then deploy into a (running) server:

    Deploying the plugin

    You can deploy the plugin in three ways, where the first one is probably the best, when developing such a plugin:

    • run mvn install above with option -Pdev - this will automatically deploy into the development containter
    • copy the plugin manually into the dropbox at $RHQ_SERVER/plugins (that directory is in parallel to bin/ and jbossas/ )
    • Deploy via GUI:

      • Go to the plugins page
        Bildschirmfoto 2009-12-15 um 21.00.37.png

        and select server plugins at the top tab
      • Scroll down to the upload box, select add, select the plugin in the open dialog and then when done, click on "upload".
      • Press "scan for updates" at the bottom of the plugin list above - it should now show up in the list of plugins

    Configuring it

    Click on "Alert:Url" in the list of plugins. This will bring you to the plugin details. And then on "Configure Alert:Url" (configuring could also happen from the Administration->System Configuration->Settings menu).

    You will see a list of plugins where the Alert:Url one is selected on the left and the current site wide preferences on the right:

    Bildschirmfoto 2009-12-15 um 21.41.18.png

    If you click on Edit, you can edit the host to some other value than the default.

    Using it in an alert definition

    Go to the usual screen for alert definitions of a resource - in the preliminary gui, there is a link To Alert sender plugins; click it.

    You will come to a screen with a drop down - select Url from it


    Click on "Go" and then in the configuration enter the port number to use. Click on "submit it".



    you have just written and deployed your first alert sender plugin for RHQ and Jopr

Monday, December 14, 2009

How to write an alert sender plugin for RHQ/Jopr (Part 1)

Now that RHQ 1.4.0-B01 is out, it is time to show you how you can easily write your own alert notification mechanism and plug it into RHQ (see also "RHQ and the future of alerts").

As an example we'll use a sender that will use a http-POST request to a remote host where the body of the request will contain the alert message (like the one you know from the existing email-sender).

But before we do this, I'll show you the bits involved, so that the source code is easier to understand.

In order to write the plugin you need two things at least:

  • plugin descriptor

  • a sender class

Sometimes you also want to implement a component class (more later).

So lets have a look at them in turn:

Plugin descriptor

The structure of the plugin descriptor, rhq-serverplugin.xml, looks like this:


It follows the schema definition in rhq-serverplugin-alert.xsd.
Elements in it are the following.
  • alert-plugin: This is the parent element for the whole descriptor. It contains the following attributes, which are all taken from the general server plugin descriptor:

    • name: name of the plugin

    • displayName: name of the plugin as it shows up in the UI

    • package: the package of the plugin. Is used to determine the fully qualified class name if it contains no package. Within RHQ, there is a naming convention of Alert:medium for this

    • description: A description of the plugin as it shows up in the list of plugins

    • version: the version of the plugin.

The first few child elements come from the general server-plugin descriptor and apply to all server side plugins.

  • help: general information about the plugin, that also shows up in the list of plugins

  • plugin-component: class name of a class that gets loaded on plugin start and stays there as a "singleton" until unload. See below.

  • scheduled-jobs: this is a configuration that allows you to have your plugin code be run at regular intervals; it is probably less of interest for alert senders

  • plugin-configuration: properties listed here will end up in the system-wide preferences system UI and serve to do general configuration of the plugin (like e.g. the name of a remote host where alert notifications should be sent to)

The next batch of elements is specific to the alert-plugins:

  • short-name: the short name of the sender. This is used e.g. in UI drop downs to select the sender

  • plugin-class: the name of the class that implements the abstract AlertSender class to build the actual sender.

  • alert-configuration: specific properties on a per AlertDefinition basis. This can e.g. be the list of email addresses the alert notification should be sent to.

  • custom-ui: this element is not yet active and is supposed to help building a custom UI if the UI via alert-configuration is not powerful enough.

The sender class

All senders need to extend the class org.rhq.enterprise.server.plugin.pc.alert.AlertSender which looks a little like this:

public abstract class AlertSender {
/** Configuration from the global per plugin type preferences */
protected Configuration preferences;
/** Configuration from the per alert definition parameters */
protected Configuration alertParameters;
/** Global component holding persistent resources */
protected T pluginComponent;
/** Do the work */
public abstract SenderResult send(Alert alert) ;

The method of interest is send(Alert) where you get the data for this specific alert passed in. You need to implement it.

The preferences or the alert definition specific properties are injected by the RHQ server, as well as the plugin component, so that you can just get your properties that you set up in the deployment descriptor via calls like this:

String hostname = preferences.getSimpleValue("hostName","localhost");

assuming that you have the following in the plugin descriptor:

<c:simple-property name="hostName" />

Component class (optional)

The component class is a class that implements the interface org.rhq.enterprise.server.plugin.pc.ServerPluginComponent. It can be used to e.g start up a connection to a remote host within the start() method and tear it down when stop() is called. You need to expect that start() and stop() can get calles multiple times during the life of a plugin.

The interface has two more methods: initialize() and shutdown() - those are called directly after loading and before unloading an alert sender. The idea here could e.g. to load an external library and unload it at plugin unload.

The component class is a "singleton" in the lifecycle of a server plugin and stays present while the plugin is loaded. It is optional for alert Plugins - if it is present, it will be injected into AlertSender.pluginComponent.

Plugin structure

The alert sender is created in the standard Maven-2 directory structure. Java sources go into src/main/java/, while the plugin descriptor goes into src/main/resources/META-INF/rhq-serverplugin.xml:

File system structure for an alert sender plugin

Round up

Ok, that's it for now. You have seen what is involved in writing an alert sender plugin for RHQ and Jopr (versions 1.4.0.B01 and up).

As always give me and us feedback - e.g. via Irc at #rhq on freenode.

Continue with part 2...

Friday, December 11, 2009

RHQ 1.4.0.B01 released - includes Jopr

The RHQ project is pleased to announce the release the first developer build of the RHQ 1.4.0 platform. This developer release, 1.4.0-B01, provides an early looks at the new features which we are planning for the 1.4.0. This release contains many of the plugins which had been available as part of the Jopr project, along with the plugins that were included in previous RHQ releases.

Note: we do not advise to upgrade any existing Jopr or RHQ installs with this build!

Check out the
Release notes.

download the software.
The individual maven project artifacts have been published to the JBoss maven repository under org/rhq/ and org/jboss/on/.

Source code can be found in the git repository at fedorahosted.

If you have questions, join us on #rhq on or use the mailing lists:

Of course you can still use the existing mailing lists and forums.

Tuesday, December 08, 2009

New experimental (ruby) script plugin for RHQ / Jopr (updated)

I've just committed an experimental 'script2' plugin to the RHQ git repository, that allows to write monitoring scripts in the Ruby programming language.

This plugin is not yet enabled in the normal build because of issues (see below) - if you want to have a look at it, go to modules/plugins/script2 and issue mvn -Pdev install.

To use the script, go to the platform and manually add a script2 resource
For the connection properties you need to specify the scripting language to use and the name of the script, which needs to exist at $AGENT/data/script2/ in the agents file system.

Your script needs to provide 3 functions: avail, metric(name) and trait(name) - here is an example to show this. By default 4 metrics named 'metric1'..'metric4' are collected as well as one trait called 'trait1'.

def avail
return 1
def metric(name)
return 4
def trait(name)
return "Hello Ruby World: #{name}"

Unfortunately there is still one issue in the code that makes the scripting engine "forget" the script, so that after some time you'll see
exceptions like the following show up:

:1: undefined method `avail' for main:Object (NoMethodError)

If you have an idea what is going on, please tell me.

Thanks to Yoko Harada I was able to isolate the issue and fix it. Basically the issue is that the script was evaluated in one thread and later its methods got invoked in other threads which did not contain the evaluated script. So now I am just always re-evaluating the script before calling invokeFunction(). This is somewhat slower, but works.

It looks like if I would use the Red Bridge api directly (which is part of the JRuby 1.4 distro), there would be a better way, but the current implementation would allow for different scripting languages. Which brings me to:

Also if you want to help to get other languages implemented, contact me.

Friday, December 04, 2009

Facelets ui:include considered powerful

Just as a preface: I am very far from being a JSF or Facelets expert - more a novice.

So lately I have been looking at how to dynamically include Facelets or general xhtml snippets into my JSF/Facelets pages. One of the tags made for this is of course <ui:include>. In its src-attribute you give a path to a page to include like <ui:include src="/path/to/file.xhtml"/>. So far so cool.

Now I want to have the page to include to be dynamic - after a lot of googling I found that I can actually pass an EL expression like this <ui:include src="#{BackingBean.path}"/>. This did first not work at all, because I had a typo in the name of the backing bean - and I just got an error "there is an error" :-/ After the typo was fixed, I was able to get the path from the backing bean.

Now there are situations where my included page can or should not be shown.

First (naive) approach was (we are using RichFaces):

<rich:panel rendered="someCondition">
<ui:include src="#{BackingBean.path}"/>

But no matter the condition, BackingBean.path was evaluated and this could return something that does not point to the file, which screwed up the whole page with the above "there is an error" message.

So I ended up with creating an empty page, that I put into the webapp and my BackingBean.path now looks like this:

public String getPath() {
if (someCondition)
return stringExpression;
return "/path/to/empty.xhtml";

This works like a charm.

And I also found out that the src-attribute of ui:include actually is an URL, which means, that it is possible to get the included snippet from a remote web site or from within a Jar file like

public String getPath() {
URL pathUrl = getClassloader().getResource("nameOnClasspath");
return pathUrl.toString();

So yes, <ui:include> is a powerful feature of Facelets.