Image by Getty Images via Daylife
I wanted a way to capture certain types of errors from an
OpenESB application, under the Glassfish application server. I had to do this because a couple of error scenarios get their exceptions handled at a lower level than my application code and I never get a chance to detect the problem. One approach to resolving this is to write some completely external process to monitor the log file itself. But a another way is to use Glassfish's Self-Management Framework, an
MBean and a rule.
There weren't a lot of examples of this to be found, so here some code. First, the MBean itself. The MBean needs to be built in conformance with some simple but very specific rules.
- It must implement javax.management.NotificationListener
- It must have an interface of its own with the same name as the MBean, but ending in "MBean"
Here is the MBean interface:
package com.log.monitor;
import javax.management.Notification;
import javax.management.NotificationListener;
public interface CustomActionMBean {
public int getA();
public void setA(int a);
}
It is a trivial Java Bean interface with one getter/setter pair added here just as an example. Here is the implementation class:
package com.log.monitor;
import javax.management.Notification;
import javax.management.NotificationListener;
public class CustomAction implements CustomActionMBean, NotificationListener {
private int a = 0;
public CustomAction() {
}
public void setA(int a) {
this.a = a;
}
public int getA() {
return a;
}
public void handleNotification(Notification arg0, Object arg1) {
System.out.println("Called... " + arg0.getMessage());
}
}
These get built into a jar file called CutomAction.jar, using whatever IDE or command line you prefer. I used
Eclipse, and I found that I had to uncheck the compression option to get this to fully work.
I deployed the jar file to Glassfish using its web-based administration console. This is done in a manner simular to deploying anything else, but using the section under "custom mbeans." There is a command line method too, using asadmin. The deployment will fail if there's anything wrong with the MBean, such as an incorrect interface name or referring to the wrong Notification classes.
Once this is done, a Management Rule can be created. The key here is that the "event type" should be "log". The MBean deployed above should appear in the "Action" drop down list. Each event type has different options. In the case of a log type it is also possible to select a log level, and a specific logger as filters. But once activated, this rule will call the new MBean as needed when an appropriate log message is created. The raw message string is available from the Notification object with getMessage().
Here's a few good resources on all this:
http://weblogs.java.net/blog/sankara/archive/2006/02/self_management.html
http://blogs.sun.com/technical/entry/self_management_rules
https://glassfish.dev.java.net/javaee5/selfmanagement/selfmanagementhome.htmlhttp://www.caucho.com/resin-3.0/jmx/tutorial/listener/index.xtp
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=9cc4357f-88cc-47aa-9ee9-428974a44a2c)
T
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=96ebeb1f-ad83-4891-81a6-c59fd5983e9d)
