Thursday, August 27, 2009

Twitter plugin + alert sender for Jopr updated

I've updated the twitter plugin for Jopr:

Manual add instead of auto discovery

The Twitter feed is no longer autodiscovered, but you have to go to the platform and explicitly add it there.

Bild 11.png

The reason behind it is that most users don't want to have a twitter feed discovered on each agent.

To learn more about auto discovery vs. manuall add, have a look at my post "Jopr plugins: Autodiscovery vs. manual add".

Support for other Twitter-like services

The plugin is now also able to post to other twitter-like services like (or your own private one based on the code).
The serverBase is for, as well as the search base.
For Twitter, serverBase is and searchBase is

If you select the right template, this will automatically be filled in for you.
Bild 12.png

Alert sender updated too

I've also updated the Alert sending in the HEIKO-EXP branch to be able to send to other networks than Twitter.
This means that in the system configuration, there is a new field for the base url of the services api. See above for possible values.


I've just seen that Twitter is offering a streaming api. This may be a nice addition to the plugin. Today every request to obtain values opens a new connection to Twitter. With the streaming api, this could probably go away.

Wednesday, August 26, 2009

Jopr plugins: Autodiscovery vs. manual add

One thing that I have neglected so far in the plugin development articles for Jopr that I wrote is the possibility to just manually add a resource instead of having it auto discovered.

Why would you want to manually add a resource?

Some resources are virtual like e.g. Twitter feeds in the twitter plugin. If you have 100 agents, it makes no sense to either take the twitter feeds into inventory on all 100 of them or to have to ignore them all in the auto discovery portlet.

When to use auto discovery then?

Auto discovery is best used for more concrete resources like e.g. processes that can exist on a system (a JBossAS for example) or file systems etc. Those are items you usually want to monitor on each system.

Ok, show me the code

Well, actually the code is not that different from what you already know. Within ResourceDiscoveryComponent.discoverResources() the change is to check for passed resource configurations and use those to create the concrete discovered resource:

for (Configuration config :
discoveryContext.getPluginConfigurations()) {
DiscoveredResourceDetails detail =
new DiscoveredResourceDetails(
discoveryContext.getResourceType(), // ResourceType
url + "_"+ user, // ResourceKey
url + " feed for " +user,
"One " + url + " user",
null );

return Collections.singleton(detail);
return null;

As the plugin container will only pass us one configuration at a time (even if the call to getPluginConfigurations() is returning a List), we can safely return the constructed detail. And this is already all :-)

One thing you need to change though is in the plugin descriptor:

description="Twitter monitoring subsystem"

This supportsManualAdd is what lets the resource type show up in its parent (usually platform for a standalone server) "Manually Add" dialog:

Bild 11.png

For more resources related to plugin development have a look at this post.

Thursday, August 13, 2009

Jopr and JBossON sessions at JBossWorld

If you're going to JBossWorld, you will find also quite some sessions about JBoss ON and Jopr:

The JBossWorld web page has the full agenda of the event.

Monday, August 03, 2009

Twitter, OAuth, Java and Twitter4j

For alert notifications in Jopr, I am using the Twitter4j library, as well as for the twitter plugin.

As Twitter now requires the usage of OAuth to register new applications, I was looking into this as well. Luckily, Twitter4j has support for OAuth.

Unfortunately this did not work for me ;-(

After some digging, I found the solution (code is the one from the samples page):


System.out.println("Open the following URL and grant access to your account:");


System.out.print("Hit enter when it's done.[Enter]:");

String pin = br.readLine();



  accessToken = twitter.getOAuthAccessToken(requestToken, pin);


So basically Twitter is returning a PIN to me after I have granted access - and this PIN needs to be passed to the call to get the auth token. This also means to use a different method than in the original example.