Start Making Sense...

SmartGWT IE7, IE8 Support

2011-05-23T09:57:00.012-04:00

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

2011-02-18T14:44:00.005-05:00

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

2010-08-19T13:27:00.002-04:00

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 + "!")

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.
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);

Use a criteria find to locate sample-bundle and retrieve it's BundleVersion info.
Again, use a criteria find to locate the group of platforms to which we want to deploy this bundle.
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.
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.
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);

Again, using criteria fetch, get the Bundle and it's destination.
Just like script 1, now create a new BundleVersion, 2.0, with a distribution fil
Showing the different versions can have different configuration needs, a new property is added.
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);

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

2009-04-30T09:53:00.006-04:00

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...

2008-06-20T16:10:00.001-04:00

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.