Introducing Hawkular Alerts!

We're happy to introduce the new Hawkular Alerts project!  For those familiar with the RHQ Project you know it has fairly powerful alerting capabilities.  Using what we learned in RHQ as a starting point we're building an alerting project that goes above and beyond what RHQ offered, and does it in a way that can be consumed by other projects, like yours!

Hawkular Alerts is one component of the new Monitoring project, Hawkular, which is also cool, starting to take shape, and is something that you should check out.

The Hawkular Alerts engine is built on JBoss Drools for fast, scalable alerting.  But you don't have to be a rules expert to use it.  Some of what Hawkular Alerts gives you:

* Flexible, multi-condition Triggers.
* Powerful "Dampening" to control your alert firing rate .
* Simple Alert Life-cycle management.
* Automated Trigger disable and enable.
* Automated Alert Resolution by detecting the end of your alerting event.
* Pluggable Action and Notification capabilities to act on your alerts.
* Complete REST API for Definition and Execution.
* Optional standalone deployment or get added value with Hawkular Metrics or Hawkular.
* Multi-platform deployment as a J2EE WAR file on JBoss WildFly.

Hawkular Alerts is available on GitHub.

Hawkular Alerts is published for maven consumption on Nexus.

Hawkular Alerts chat on #Hawkular at irc.freenode.net.

Hawkular Alerts discussion on the Hawkular developers mailing list.

Hawkular Alerts  Developer and REST API documentation at Hawkular.

The project is **NEW**!  We value your feedback, ideas and contributions!

Hawkular Alerts is open source, by us and for us, actively being developed at Red Hat.

Jay + Lucas

jshaughn@redhat.com

lponce@redhat.com

RHQ Group Definitions (dynagroup) Enhancement

The RHQ Project supports Group Definitions, also known as DynaGroups, to let users automatically generate resource groups given a powerful expression language.  For example, if I'm managing a bunch of JBoss AS7 Servers I may want to automatically group them so I can process them together.  Instead of creating and populating a  resource group manually, I could also just create a Group Definition like: 

resource.type.plugin = JBossAS7
resource.type.name = JBossAS7 Standalone Server

Moreover I could even have it automatically recalculate the group membership at some interval to my liking. Here is a link for a complete rundown on Group Definitions.  

This blog is to point out a nifty new feature for limiting generated group membership by providing one or more narrowing groups.  We've added the 'memberof' expression to the group definition language.

Let's say you're managing a bunch of machines and you've got them split up between two teams.  You've already imported your platforms into RHQ and created a couple of groups (either manually or with dynagroups) such that you have Platform Group A and Platform Group B, and your two teams are assigned views of these two groups appropriately (RHQ provides a robust Role Based Security Model). As a note, these are recursive groups, meaning they implicitly include all of the resources for that platform.

Now let's say a few team members are devoted to your AS server management and require heightened permissions for the servers they manage, say deployment permissions.  I create a new role with the desired permissions and assign the users. What I need is to easily create a group of the servers that they can see, and assign it to the role in order to tie together the users, the permissions and the server resources. I can do that by using the same Group Definition above, but with one more expression:

resource.type.plugin = JBossAS7
resource.type.name = JBossAS7 Standalone Server

memberof = Platform Group A

The groups generated are now guaranteed to be limited to only those servers that are in Platform Group A. Put another way, the results are narrowed by Platforms Group A. It is valid to supply multiple 'memberof' expressions in one group definition.  In this case the resulting dynagroups will be limited to resources in the union of narrowing groups. This feature can play a big role in role-based security in RHQ, but has other uses as well.  Use it any time it would be helpful to generate proper subsets of existing groups.

Enjoy!

Store your RHQ Agent Preferences in a File

The RHQ Project stores its agent configuration using Java Preferences, which is a great way to store things in a platform-independent way without having to worry about it.  But, sometimes it's nice to have a little more control over things, especially on Windows where the native implementation uses the registry.  Some RHQ users have requested being able to store the agent configuration in a configurable file, so that they can just wipe an agent directory and not leave any configuration litter somewhere on the machine.

I recently pushed this feature to our master git branch and it should show up in RHQ 4.7.  But you can try it now if you roll your own builds.

All you need to do is start your agent with two system properties set:


java.util.prefs.PreferencesFactory=org.rhq.core.util.preferences.FilePreferencesFactory 
rhq.preferences.file=


This can be done conveniently by setting them in rhq-agent-env.sh|bat:

set RHQ_AGENT_JAVA_OPTS=-Djava.util.prefs.PreferencesFactory=org.rhq.core.util.preferences.FilePreferencesFactory -Drhq.preferences.file=

You can omit the rhq.preferences.file property and it will default to user.home/.fileprefs but you probably don't want to use the default.  A more likely approach would be to set it to something like:

 -Drhq.preferences.file=$RHQ_AGENT_HOME/conf/agent-prefs.properties

By doing that you'll be storing it under the agent's root, and therefore if you delete the entire agent you'll also get rid of the prefs.

Note that this works easily for new agents.  For existing agents that want to switch to this approach, it will be somewhat like starting with the --fullcleanconfig option.  This means you'll need to re-enter the setup questions and also specify the existing security token via -Drhq.agent.security-token=.  If you want to see your existing configuration settings before making a switch you  can use the '> config list' agent prompt command (either interactively or via the RHQ Agent's operation).

Arquillian and TestNG

The RHQ Project has historically run on JBoss AS 4.2.3.  That is changing as we leap forward to JBoss AS 7.1.1.Final for our next release.  There are a lot of advantages to this move but it also presented a lot of challenges, one of which was our integration test approach. 

When deployed on AS4 RHQ used the JBoss Embedded Container to perform unit/integration tests on domain (JPA persistence) and server jar (SLSB) classes. Now that we deploy on AS7, the embedded container was no longer an option. The de facto alternative is Arquillian. Arquillian is a tool that integrates multiple test frameworks, namely JUnit and TestNG, against several containers, namely Glassfish, OpenEJB and, most importantly for us, AS7.

For a more detailed account of this change in RHQ, see this wiki page about the testing impact.  Here I will just summarize some lessons learned and tips for using Arquillian with TestNG.
This is written with reference to Arquillian version 1.0.2.


Arquillian runs the TestNG lifecycle for every test

This is critical to understand. It means that BeforeXXX/AfterXXX methods are all called for every test. Effectively this means that the only methods you can effectively use are BeforeMethod and AfterMethod.

Avoid BeforeClass/AfterClass or other flavors of these methods.

If you absolutely must you may be able to use "stand-ins" for these by using @Test methods instead. By using dependencies, or priority, you can sort of simulate BeforeClass and AfterClass. But note that test priority is evaluated only in the scope of the group its test is in. Also realize that BeforeClass and AfterClass often cause unexpected issues due to test class interactions, and stand-ins can present the same problems. Any startup/teardown actions must be impervious to random test orderings amongst all classes.

Do not share data with instance variables.

The test class is effectively new'd for each test. This can make life difficult. Even though dependencies in test order execution are honored, it does not mean that you can set variable 'foo' in testA and use the value of 'foo' in testB. You have a few alternatives:

• Store and fetch data in the DB.
  This only works if the DB data somehow survives the local Before/After methods, and those of any other test class.

• Store and fetch data to a file by serializing data.
  A simple util is available in AbstractEJB3Test. (This is the class that all of the relevant RHQ integration tests extend. Feel free to take a look.)

• Just write a single, big test, that spans all of the tests you were thinking of splitting up and sharing data between.
  This is probably the easiest route. In this case I suggest writing the tests separately, as private methods, as if they were real tests. And then creating a single consolidatedTest that calls them each in order.

Know that BeforeMethod and AfterMethod are actually invoked twice per test.

Arquillian has two modes of testing, client and in-container. Client testing is such that the tests are basically remote clients and hit the deployed server in that fashion. We use the other mode, which is to run the tests in the container, meaning we can inject InitialContext, EntityManager, etc.. into the tests. Due to architectural integration issues, Arquillian calls BeforeMethod twice, once for each mode. We need to execute our code only for the in-container invocation.

The preferred mechanism for a BeforeMethod or AfterMethod is now to extend the base class methods offered in AbstractEJB3Test. So:

// NOT recommended
@BeforeMethod
public void myBeforeMethodName();

// Recommended
// By overriding the method you'll get built in in-container invocation only, as well as standard error handling.  Note that there are a few flavors
// of the method, some taking parameters.
// IMPORTANT: use protected, not public.  Public methods are considered test methods by testng if the class is annotated with @Test.
@Override
protected void beforeMethod();

// If you must use the annotation ensure you protect the invocation
@BeforeMethod( some attributes you just have to have )
public void myBeforeMethodName() {
  if ( !inContainer()) {
    return;
  }
  ...
}

Know that false positives result if exceptions are thrown in BeforeMethod

Warning! Currently if an exception is thrown from your BeforeMethod it will be swallowed and the test will appear to pass. I'm not sure if there is a way to get the test to fail, currently I am wrapping the logic in a try/catch and printing blatant warnings in the output.

Know that there is an extension for running several test classes against a single deployment

By default Arquillian with testng will for each class in the test suite:

1. Start container
2. Deploy test deployment
3. Undeploy test deployment
4. Shutdown container

Although good for test exclusivity, it is prohibitively slow for a project with many test classes that doesn't need that level of test isolation. Working with the Arquillian developers we've put in place an Arquillian extension that allows us a single container start and deploy. Our extension has only nominal changes applied to the extension provided at https://gist.github.com/3975179.

It should be noted that this extension uses Arquillian's (not testng) BeforeClass/AfterClass hooks, so those become unavailable for other use, but that is not an issue for us as we don't have any other extensions and observing those (or any other) events.

Hope this helps.

Marking target directories derived for Eclipse Maven projects

Just a quick one.  It drives me crazy when I do a search in our maven-based Eclipse project and it includes all the class files etc found in target directories.  This is one way around it.

There may be better ways to do this because for one, Monkey scripting for Eclipse seems to be archived.  And two, I can see that Eclipse has a variety of change requests for supporting this natively.  But although I can see the support for derived files/folders in Eclipse, I couldn't see a built-in way for marking Maven target directories as derived in some automated way.  And Resource filtering was too aggressive as it affected the project building.

On the RHQ Project we had an older script to do this, written in Javascript and using an old Monkey script plugin.  This is an adapted script for a newer (although maybe still old) plugin called GroovyMonkey.  You can install it into Eclipse from here:

http://groovy-monkey.sourceforge.net/update 

Use the plugin to create a new script.  It will have given you a new Groovy Monkey entry on the main menu and will add a new GroovyMonkyScripts project for you.  Make the name (you'll need to check the 'override' box):

MakeTargetsDerived_Python.gm

Here is the script:

==================================================================
/* 
 * Menu: Make Targets Derived > Python
 * Script-Path: /GroovyMonkeyScripts/monkey/MakeTargetsDerived_Python.gm
 * Kudos: jshaughn
 * License: EPL 1.0
 * LANG: Python
 * Job: UIJob
 */

# Install GroovyMonkey from:
#   http://groovy-monkey.sourceforge.net/update
#

files = resources.filesMatching(".*/pom\\.xml")
for file in files:
  targetFolder = file.eclipseObject.parent.findMember("target")
  if targetFolder != None:
    targetFolder.setDerived(True)

files = resources.filesMatching(".*/dev-container/jbossas/bin/run\\.sh")
for file in files:
  files.eclipseObject.parent.parent.parent.setDerived(True)

window.getActivePage().showView( 'org.eclipse.ui.views.TaskList' )
==================================================================

Only the first for loop is working on the target folders, the second pass is just for our own benefit but shows that you can add as many different file pattern sections as you like.

Hope this helps..

Availability Duration Alerting in RHQ/JBossON

Red Hat has recently released version 3.1 of JBoss ON (JON), built on the upstream RHQ Project. RHQ version 4.4 made significant improvements to Availability handling.  Availability is a critical management component, basically monitoring and reporting on whether your resources are running (UP) or not (DOWN).  For an overview of the availability changes in RHQ 4.4, both performance enhancements and new features, see the RHQ wiki.   You can also check out the blog by Mazz that talks in some more detail about some of the changes.

Here I just want to bring to your attention the cool new feature of Availability Duration alerting.  Prior to this release RHQ had the ability to alert only on availability state changes.  Specifically,  "Goes DOWN" and "Goes UP".  This was very rigid because it means you'll generate alerts on brief periods of down time, even if that downtime was anticipated.

In many real-world use cases you'd prefer to be alerted only if an resource goes down and "Stays DOWN" for a certain length of time.  This is what Availability Duration alerting is all about.

The following demo, about 5 minutes long, walks you through the new feature with a simple example:

If you were watching closely you may have noticed a few other things, like the quick availability reporting after lifecycle events.  That is just one of many improvements for making availability reporting more timely and therefore more useful.

We're always interested in feedback, let us know what you think by commenting here, on the rhq-users mailing list, or #rhq on freenode!  Thanks!

Jboss ON and Reactive Alert Handling

Red Hat has recently released version 3.0 of JBoss ON, built on the upstream RHQ Project. There are several cool features in 3.0, but more than that, the feature set integrates more than ever before. This example shows how several subsystems can come together to handle some high level tasks.

The following demo features reactive alerting, meaning, the ability to automatically take corrective action in response to an alert fired in your environment. It combines the new Drift Management feature, for detecting configuration drift, Alerting to notify that drift has been detected, JON's CLI Scripting for reacting to the alert, and Bundle provisioning for correcting the situation. Also, the new JBoss ON GUI, written in SmartGWT, is on display.

You can watch the demo here, and then take a look at some of the details below.

RHQ Demo: File remediation using alert CLI notification, drift detection and bundles

The demo showed how you can monitor your system for file drift, and alert on that drift when detected. And then how that alert can in turn invoke RHQ CLI scripts to take action. The RHQ CLI is powerful, it offers a robust API and many built-in features, in a Rhino Javascript environment. In the example we use the following script, which calls into the RHQ server and leverages the remote API for bundle provisioning. Here is the script for reference:

//
// This script performs some mock remediation on Drift detection by performing
// a clean bundle deploy of the corrupted file.
//

// note, the 'alert' variable is seeded by the alert sender

// Log what we're doing to a file tied to the fired alert id
//
var e = exporter
e.setTarget( 'raw', 'c:/temp/alert-cli-demo/logs/alert-' + alert.id + '.log' )

// Dump the alert
//
e.write( alert )

// get a proxy for the alerted-on Resource
//
var alertResource = ProxyFactory.getResource(alert.alertDefinition.resource.id)

// Dump the resource
//
e.write( " " )
e.write( alertResource )


// Remediate file

// Find the Bundle Destination
//
var destCrit = new BundleDestinationCriteria()
destCrit.addFilterName('Alert CLI Demo')
var result = BundleManager.findBundleDestinationsByCriteria( destCrit )
var dest = result.get( 0 )

// Find the Bundle Version
//
var versionCrit = new BundleVersionCriteria()
versionCrit.addFilterVersion(1)
result = BundleManager.findBundleVersionsByCriteria( versionCrit )
var ver = result.get( 0 )

// Create a new Deployment for the bundle version and the destination
//
var deployment = BundleManager.createBundleDeployment(ver.getId(), dest.getId(), 'remediate drift', new Configuration())

// Schedule a clean deploy of the deployment. This will wipe out the edited file and lay down a clean copy
//
BundleManager.scheduleBundleDeployment(deployment.getId(), true)

e.write( " " )
e.write( "REMEDIATION COMPLETE!" )

The demo neglects to show the resulting log file. The log file gives you an idea of what the alert variable data looks like. The alert data, which is provided to the script automatically, allows the script writer to access lots of other information he may need. In this example, the resource info. Here is the log file generated by the demo:

Alert:
        acknowledgeTime: -1
   acknowledgingSubject:
        alertDefinition: org.rhq.core.domain.alert.AlertDefinition[ id=10001, name=Drift!, conditionExpression=ANY, priority=Medium, resourceId=10001 ]
  alertNotificationLogs: []
          conditionLogs: [org.rhq.core.domain.alert.AlertConditionLog[ id=10191, value=Drift Detected, extraInfo=[[Fri Jan 27 17:19:53 EST 2012] Drift detected in [1] files using drift definition [Alert CLI Demo]], org.rhq.core.domain.alert.AlertCondition[ id=10041, category=Drift Detected, name=Alert CLI Demo, comparator='null', threshold=null, option=null ] ]]
                  ctime: 1327702795100
                     id: 10181
recoveryAlertDefinition:
             recoveryId: 0
            willRecover: false

ResourceClientProxy_$$_javassist_138:
                       OSName: Win32
                    OSVersion: 6.0
                 architecture: x86
                     children:
                 contentTypes: {InstalledSoftware=Installed Software}
                  createdDate: Mon Jan 23 14:11:38 EST 2012
                  description: Microsoft Windows Operating System
                   freeMemory: 805.0MB
                freeSwapSpace: 3.9GB
                      handler:
                     hostname: jshaughnessy-PC
                           id: 10001
                         idle: 0.0%
                 measurements: [Wait Load, Used Memory, System Load, Total Memory, OS Name, Free Memory, Hostname, Architecture, Idle, Total Swap Space, Used Swap Space, User Load, OS Version, Free Swap Space]
                 modifiedDate: Mon Jan 23 14:11:38 EST 2012
                         name: jshaughn
                   operations: [viewProcessList, manualAutodiscovery]
          pluginConfiguration:
pluginConfigurationDefinition: ConfigurationDefinition[id=10136, name=Windows]
                 resourceType: Windows
                   systemLoad: 0.0%
                  totalMemory: 3.0GB
               totalSwapSpace: 7.4GB
                   usedMemory: 2.2GB
                usedSwapSpace: 3.5GB
                     userLoad: --no data available--
                      version: Win32 6.0
                     waitLoad: 0.0%

REMEDIATION COMPLETE!

The above script begins to help you build your own, but JBoss ON (and RHQ) include a more powerful base script for putting together a CLI-based provisioning solution. It can be downloaded in the GUI, via Administration->Downloads.

Enjoy!

SmartGWT IE7, IE8 Support

Version 4.0.1 of the RHQ project adds IE7 and IE8 support. It took a bit of wrangling to figure out how best to support IE with our spiffy new SmartGWT interface. There are a few parts in play:

• IE version (7,8,9...).
• IE Mode (quirks, standards7, standards8, standards9...)
• SmartGWT version
  
• GWT build user.agent values (ie6, ie8)

Our goal is to function with IE7, IE8 and going forward, IE9 and onwards.

One big blocker we ran into is that if you don't quite get things lined up in the build you can get a situation where IE simply will not load. The behavior basically looks like a GET request, usually with high CPU, hanging while waiting for a response for either CSS or JavaScript. Very hard to do much when you hit this.

I'm not going to go into the details too much, here's pretty much the end-game:

Use a recent version of SmartGWT: Version 2.2 or later. We're on 2.4. This in itself solves an older issue with IE not being able to handle larger chunks of JavaScript. Later versions of SmartGWT chunk the generated JS.

Stick with Quirks Mode: This is recommended by SmartGWT because they already code for the quirks of the browser vendors. That's pretty much what you're getting with your permutations you ask for in the build.

Don't use DOCTYPE in your bootstrap HTML: This is also recommended by SmartGWT because the presence of a DOCTYPE decl will send IE into standards mode for that version of IE. It also affects other vendor's behavior so really, it changes quite a lot. We were initially lured to DOCTYPE because it solved the hanging load issue, but it caused several rendering issues later on.

Do use the meta tag to declare IE7 emulation: This avoids the DOCTYPE problem, will be used by IE8 onwards, and will be ignored by other browser vendors. So basically, if your GUI is working well for IE7 you have a pretty good chance of forward compatibility. It's placed right at the top, just inside the head tag, like this:

<html>
<head>
<meta http-equiv="X-UA-Compatible"
content="IE=EmulateIE7" />
...
</head>
</html>

The content="IE=7" will give you standards mode, which causes other rendering issues as mentioned above. Also, any attempt to use IE8 modes resulted (at least with SmartGWT 2.4) in issues with TreeGrid rendering; unindented child nodes and excessive vertical spacing. This was true even with the SmartGWT showcase. There is definitely an issue between SmartGWT and IE8 for trees.

Use the IE6 GWT user agent: You must include the "ie6" GWT user agent in your build. We're emulating IE7 and that requires the "ie6" userAgent. If you don't include this you will get the hanging loading issue mentioned above.

Tip: Starting with IE8 (I was using IE9) you get a nice feature by hitting the F12 key. This console allows you to easily see and modify the browser mode and standards/quirks mode settings currently in use.

Hope this helps...

SmartGWT Tip - Regex Evaluation

The RHQ project is building a new user interface using GWT (actually, SmartGWT). There is a definite learning curve to SmartGWT but overall I think this is a great technology for UI building. It offers a rich set of GUI Widgets, a strong architecture, an active community, and responsive developers. But maybe best of all, since you can write your GUI in Java, it can quickly enable a historically non-GUI Java programmer (like me) to contribute to a GUI implementation. As we move forward I'll try and share some tips about things we've stumbled over.

Tip: Remember that hosted mode (i.e. dev mode) is driven by Java, but your standard runtime environment is JavaScript.

GWT takes your Java code and generates vendor-specific JavaScript. This is great in that it frees the Java developer from having to, for the most part, deal with JavaScript or certain vendor-specific browser differences. But, during development you'll be running in hosted mode in order to run with a JPDA debugger, and to evaluate code changes quickly. As you learn quickly in GWT, not everything in Java is available in GWT, because it needs to be able to be supported in the resulting JavaScript. But even the things that are supported may not behave exactly the same way. One example is regular expression (regex) evaluation.

In most cases the evaluation will be the same. But, you may want to test patterns you're using in both a Java regex evaluator and a JavaScript regex evaluator, ensuring they behave the same way.

I ran into this sort of regex problem recently. Here is a slightly contrived example:


(foo|foo/bar)/[^/]*

I wanted to match path segments like: foo/1234 or foo/bar/1234

In Java (i.e when running in dev mode for GWT) this worked just fine, both of the sample paths matched just fine.

The match went like this:

"foo/1234"
(foo|foo/bar) matched "foo"
/[^/]* matched "/1234"

"foo/bar/1234"
(foo|foo/bar) matched "foo/bar"
/[^/]* matched "/1234"

But in JavaScript the second example did not work as I expected.

"foo/1234"
(foo|foo/bar) matched "foo"
/[^/]* matched "/1234"

"foo/bar/1234"
(foo|foo/bar) matched "foo"
/[^/]* failed "/bar/1234"

After matching the first OR option, it did not try the second one, despite the fact that the overall match failed.

The solution was to order the OR options from most complex to least complex, avoiding the subtle issue created by option 1 being a substring of option 2:

(foo/bar|foo)/[^/]*

The left to right evaluation now gave us the desired result.

This is not a blog about regex handling, there are probably several ways to do what we wanted, and we're not encountering a bug here. This is to point out a fundamental design point in GWT development, keep in mind that dev mode and production mode have different runtime environments that can produce subtle differences in behavior. For the same reason you're sure to encounter entire Java classes that work in dev mode and are not available in production mode, because they aren't supported in the JavaScript environment.

Scripted Provisioning with RHQ 3.0 and JON 2.4

The new JBoss Operations Network (JON) 2.4.0, and its upstream project RHQ 3.0.0, introduce provisioning. Users can now begin to manage content distribution via RHQ by deploying bundles to managed platforms, and laying them down with flexible Ant scripting. RHQ can help manage and track different bundle versions on different destinations with varied configuration. Deployments can be upgraded and reverted as well, on groups of mixed platforms. And all deployments generate extensive auditing. For more information on provisioning see the docs.

For a gui-based demo, check out Mazz's blog entry. (note, the gui has been improved since this demo was recorded.)

I want to discuss RHQ provisioning via CLI scripting. RHQ has a powerful CLI for interactive use or for executing scripts via the Rhino Javascript engine.

Most of what you can do via the RHQ GUI can also be done via scripting, allowing IT managers to automate their processes. RHQ's Remote API is fully accessible as well as CLI features that can further simplify your scripting. The RHQ Git repository houses the following four sample scripts that I'll talk through. For the full set of commented, repeatable scripts go here. I'll just cover the snippets that do the provisioning work...

By the way, here are instructions to install the CLI.

A Bundle is basically some logical content, like an application, that you want to deploy out to your RHQ managed platforms. This example will use a bundle named sample-bundle.

Script 1: Create version 1.0 of sample-bundle

       // create bundleVersion 1.0 for the sample bundle
       var distributionFile = new java.io.File(bundleDistroV1Path);
[1]    distributionFile = new java.io.File(distributionFile.getAbsolutePath());
[2]    var bundleVersion1 = BundleManager.createBundleVersionViaFile(
                              distributionFile);
       print("\nCreated " + bundleVersion1 + "!")

1. Get the bundle distribution file path. This is a zip file containing the Ant deploy recipe and the files to be deployed. In this an example, a simple WAR file. The recipe let's us know this is V1.0 of sample-bundle. The distribution files are provided along with the scripts in the git repo link above.
2. Call the RHQ Server and have it create the new bundle, starting with bundle version 1.0. Note that in this case the bundle file is small so we just send it in one shot, the API provides for streaming alternatives for larger distributions.

Script 2: Deploy version 1.0 of sample-bundle
[1]    // get the bundle
       var bundleName = 'sample-bundle';
       var bc = new BundleCriteria();
       bc.addFilterName(bundleName);
       bc.fetchBundleVersions( true );
       var bundles = BundleManager.findBundlesByCriteria(bc);
       var bundle = bundles.get(0);
       var bundleVersion = bundle.getBundleVersions().get(0);

[2]    // get the "platforms" group
       var rgc = new ResourceGroupCriteria();
       rgc.addFilterName("platforms");
       var groups = ResourceGroupManager.findResourceGroupsByCriteria(rgc);
       var groupId = groups.get(0).getId();

[3]    // create a destination for the deployment
       var dest = BundleManager.createBundleDestination(
                      bundle.getId(),
                      "sample destination",
                      "sample destination",
                      "/tmp/sample-bundle",
                      groupId);

[4]    // create a config for the V1.0 deployment
       // setting the required properties for recipe in distro 1.0
       var config1 = new Configuration();
       var property11 = new PropertySimple("sample.name", "V1 Name");
       config1.put( property11 );
       var property12 = new PropertySimple("sample.port", "11111");
       config1.put( property12 );

[5]    // create a deployment for sample bundle 1.0 using the 1.0 config
       var deployment = BundleManager.createBundleDeployment(
                            bundleVersion.getId(),
                            dest.getId(),
                            "Deploying Sample Ant Bundle V1",
                            config1);
       deployment = BundleManager.scheduleBundleDeployment(
                            deployment.getId(),
                            true);

1. Use a criteria find to locate sample-bundle and retrieve it's BundleVersion info.
2. Again, use a criteria find to locate the group of platforms to which we want to deploy this bundle.
3. A bundle is deployed to a *Destination*, which is basically a combination of a platform group and a deploy directory. The deploy directory is where the deployment will be rooted on each of the target platforms. Note that the platform group can be of mixed platform types.
4. A bundle *Deployment* is basically a combination of a bundle version, a destination, and a *Configuration*. Here we define the configuration that will be used for this deployment. The same bundle version may need to be provisioned to different platforms with different configuration. In this case we have name and port values that will be applied on the target deployments.
5. Finally, we create the BundleDeployment and then schedule it for execution. Note that in the first release only immediate schduling is available. The sample-bundle, version 1.0 will be provisioned to the /tmp/sample-bundle directory on each member of the platforms group, and configured with name="V1 Name" and port 11111.

Script 3: Upgrade to version 2.0 of sample-bundle to the same Destination.
[1]    //get the bundle if it exists
       var bc = new BundleCriteria();
       bc.addFilterName(bundleName);
       bc.fetchDestinations( true );
       var bundles = BundleManager.findBundlesByCriteria(bc);
       var bundle = bundles.get(0);
       var dest = bundle.getDestinations().get(0);

[2]    //create bundleVersion 2.0 for the sample bundle
       var distributionFile = new java.io.File(bundleDistroV2Path);
       distributionFile = new java.io.File(distributionFile.getAbsolutePath());
       var bundleVersion2 = BundleManager.createBundleVersionViaFile(
                                distributionFile);

[3]    //create a config for the V2.0 deployment
       var config2 = new Configuration();
       var property21 = new PropertySimple("sample.name", "V2 Name");
       config2.put( property21 );
       var property22 = new PropertySimple("sample.port", "22222");
       config2.put( property22 );
       var property23 = new PropertySimple("sample.new", "V2.0 ONLY!");
       config2.put( property23 );

[4]    // upgrade the deployment to 2.0 using the 2.0 config
       var deployment = BundleManager.createBundleDeployment(
                            bundleVersion2.getId(),
                            dest.getId(),
                            "Upgrading Sample Ant Bundle to V2",
                            config2);
       deployment = BundleManager.scheduleBundleDeployment(
                            deployment.getId(),
                            false);

1. Again, using criteria fetch, get the Bundle and it's destination.
2. Just like script 1, now create a new BundleVersion, 2.0, with a distribution fil
3. Showing the different versions can have different configuration needs, a new property is added.
4. Just like script 2, deploy to the same destination, this time version 2.0. The sample-bundle will be upgraded on each member of the platforms group, same directory, new configuration applied.
   

Script 4. Revert back to version 1.0
[1]     //revert the live V2 deployment to the replaced V1 deployment
        var deployment = BundleManager.scheduleRevertBundleDeployment(
                         dest.getId(),
                         "Reverting Sample Ant Bundle from V2 to V1",
                         false);

1. Omitted is a criteria search for the bunde information, as shown in script 3. here we ask to revert the live deployment, version 2.0, to the version it had replaced, version 1.0.

All of this can be done via the RHQ GUI as well. The GUI of course can show details of everything involved, including the audits for the individual resource deployments. The API can also provide this information to the CLI, mainly via criteria fetches asking for various data to be supplied with the results.

Provisioning is a major new feature in RHQ 3.0.0 and JON 2.4, check it out!

Jopr 2.2 adds Tomcat Management

Version 2.2.0 of the Jopr management platform has been released today. It is a powerful system that allows you to manage a complex, distributed environment of deployed hardware and software. Jopr has a plugin architecture allowing different plugins to provide management for specific products or systems. Jopr provides strong management support for environments running JBoss Application Servers but out of the box provides a large set of plugins for managing an entire system. For example, platform plugins (Linux, Windows), database plugins (Oracle, Postgres), Hibernate, Apache web server, and many, many more.

A major addition in Jopr 2.2 is the Tomcat plugin, introducing powerful management for standalone Tomcat environments via Jopr. Jopr already provided support for Tomcat embedded in JBoss Application Server and the new Tomcat plugin completes the picture.

The beauty of Tomcat management with Jopr is that Tomcat is often only one piece of your infrastructure. With Jopr you get seamless, holistic management of your whole, distributed, environment, from hardware, to middleware, to applications. And, Jopr is completely extensible, allowing easy custom plugin writing and deployment.

OK, let's take a look at what the new Tomcat plugin provides.

Discovery

• Automatic discovery of your running Tomcat Servers
• Manual discovery of Tomcat Servers.
• Hierarchical inventory of your Tomcat Server's resources

As Jopr utilizes the Tomcat JMX Beans your Tomcat server does need to be enabled for remote JMX access. Secure, authenticated JMX is supported.

Control

• Server: Start, Shutdown, Restart, Save Configuration
• Connector: Start, Stop, Pause, Resume
• Application: Start, Stop, Reload

Any Jopr Operation can be executed immediately or flexibly scheduled for future or repeated executions. Operations can also be executed in response to the firing of a triggered alert.

Web Application Management

• Web applications offer a full slate of management and monitoring options.
• Control operations
• Deploy/Undeploy
• Version control
• URL specific response time monitoring
• Application cache monitoring
• Powerful metric collection

Configuration
Configuration changes to the Tomcat Server are applied immediately and persisted, surviving Tomcat restarts.

Virtual Host Management
Supports management of multiple hosts and configuration of deploy options for the hosts.

User Management
For environments using Tomcat's default Realm and supplied User Database, manage your users with immediate and persisted updates.

• Role: Create/Delete/Assignment/Configuration
• User: Create/Delete/Configuration
• Group: Create/Delete/Assignment/Configuration

And More...

• Connector Management
• Threadpool monitoring
• Powerful monitoring of the Tomcat Server JVM

And the Tomcat plugin gets all of the Jopr infrastructure for free! Jopr gives you:

Cluster Management
Group together resources of the same type, like your Tomcat Servers, and immediately see a cluster view of your resources, easily pointing out similarities and differences. Perform configuration update or operations across the cluster.

Availability, Monitoring, Metric gathering and Charting
See your data graphically, with personal views and overlayed metric charts. Granular metric collection scheduling and access to plenty of historical data. Plus, aggregate views for manually created or autogroups.

Alerting and Operations
Define simple or complex alerts with various notification options. Schedule immediate or scheduled operations.

Resource Summary and Timeline
A Quick summary of important activity for any Tomcat resource. Plus, a timeline view for correlating availability, operations, alerts and other activity for your resource.

Security
Complete role-based and permission based security for Jopr users limits access to and authorization of inventoried resources.

If you've used Jopr for your management needs in the past then this adds one more tool for you to use. If you haven't I hope you found this brief introduction useful. Download Jopr 2.2.0 and let us know what you like and what you'd still like to see for Tomcat management in Jopr.

JBoss Operations Network, JBossON, JON, RHQ : Whats in a name...

Usually folks know less than they think they do. Occasionally, though, you know more than you may think. You may know quite a lot about something but can't participate due to a language barrier. This isn't always due to a geographical language issue, but in the tech-community it happens because tech-speak can be like listening to a foreign language. Tech-speak is abbreviated, It uses a lot of acronyms and is littered with enormous amounts of context and presumption. It's used to minimize conversation while maximizing content. Or, sometimes it's just used to impress, buzzwords thrown out like Hollywood name-drops. But, often enough two people seem to be understanding each other while I am thoroughly mystified. The same thing happens when I get hit with academic-speak. I usually need stuff spelled out for me, just just a little bit, and then perhaps I may be able to offer something valuable. Of course, a tech-savvy academic from another country is my worst nightmare. Reminds me of a guy named Boris, but wait, I digress...

All I want to do here is ensure that if you hear or see any of the following names, and you know about one of them, you actually know about all of them!

JBoss Operations Network is a management system aimed at managing deployments of JBoss Application Servers. It offers all kinds of great management features already described and demoed here. V2.0.0 is available now and V2.0.1 will be available probably by the time you read this entry. JBoss is a division of Red Hat.

JBossON is in fact, the longer acronym for JBoss Operations Network and is the management-preferred acronym for the product.

JON is a further distillation and used most often due to its brevity, and its real-name-ness. But, certainly, if you see this acronym you'd never guess what it refers to.

RHQ is an open-source project on which JON is built. It is a collaboration between Red Hat and Hyperic, hence the obvious RHQ acronym. What's not obvious is that 90+ percent of JON is in fact available as RHQ. Its also not obvious that RHQ has to do with JBoss management. You can learn about and participate in the RHQ community starting here.

If you knew all of this already, great, next time we'll get into some detailed tech-speak about how RHQ's alert sub-system can make life easier for the IT pro or for managing your own laptop.