Stéphane Nicoll’s Thoughts Welcome Guest | Login or Register

I will attend one of the most interesting Java conference in europe, Javapolis. I hope to find maven people over there. I am also willing to talk to atlassian and jetbrains people. And, why not, I might talk to our very dear Hani.

I don’t know if I will be able to communicate but if so, I’ll try to summarize interesting stuff over here!

Ouch, it’s been a few days now that my Gmail account is down.

Sorry… account maintenance underway

We’re currently performing some unexpected maintenance on your account. While we can’t predict exactly how long it will take, we’re working as quickly as we can to restore access to your email–apologies for the inconvenience.

If you have questions, please contact us at gmail-maintenance@google.com.

I searched the web about issues related to gmail and found this post. I hope I won’t lost any mail (it could happen according to this post!). Anyway, if you did send me mails lately, please try again to this address. I just changed the forward so that it goes to another email account.

Let’s cross fingers …

One of the great feature of Java2 Enterprise Edition is its messaging system, defined by the Java Message Service specification.

I won’t explain the basics of JMS, please check this tutorial for more details. There are good materials regarding JMS on the Internet but I think that exception handling is not correctly covered.

How can we handle exceptions in services invoked asynchronously? Well, I would say that this fall into two main principles:

1. Use typed exceptions
2. Provide information about the exceptions and ways to handle them

Let’s say that a service is invoked with an instruction stored as a JMS message. A pattern defines this scenario, see the Service Activator pattern (Gosh, I just realized that I was stupid enough to buy a book whose content is on the Internet - shame on me!). Basically, it says that the Message Driven Bean should simply create the Instruction from the JMS message and invoke some business component with the instruction. Let’s KISS, shall we? (Keep It Stupid and Simple, stop dreaming).

Now, the processing of the instruction by the business component might fail for lots of reasons. The first thing to do is to type your exceptions in order to know whether it is recoverable or not. Unrecoverable exceptions are, for instance, an invalid instruction, a missing component needed to process the instruction, etc. Those means that in any case the instruction could not be processed with the data currently available. Recoverable exceptions are, for instance, a failure to access a J2EE component, a database error or timeout, a connection timeout with the JMS server, etc. Exceptions could even be subsclassed so that you can provide a specific message about the exception. Based on this, a single entry point for exceptions handling can be defined as follows:


/**
* Handles recoverable exceptions.
*
* @param inst the instruction that could not be processed
* @param props the jms message properties
* @param context the reason why the instruction is refused
* @param t the exception
*/
protected void handleError(Instruction inst, Properties props,
String context, Throwable t) {
// Does not throw any exception
rejectedInstructionHandler.
processRejectedInstruction(inst, props, context, t);
}

The message driven bean should only invoke the business component with the message and handle JMS specific exceptions as well as exceptions while invoking the business component itself.

public void onMessage(Message msg) {
try {
// Get the representation of the message - assume that TextMessage is sent
String xmlInstruction = ((TextMessage) msg).getText();
// jmsProperties contains the message properties and the destination
// where it was received
instructionHandlerHome.create().
processInstruction(xmlInstruction, jmsProperties);
} catch (JMSException e) {
logger.error(”Failed to get message content”, e);
ctx.setRollbackOnly();
} catch (CreateException e) {
logger.error(”Could not create instruction handler instance”, e);
ctx.setRollbackOnly();
} catch (EJBException e) {
logger.error(”Unexpected error”, e);
ctx.setRollbackOnly();
}
}

The business component should catch each and every exception with an appropriate error message. For instance:

public void processInstruction(String xmlInstruction, Properties properties) {
Instruction instruction = null;
try {
// Get the instruction
instruction = instructionParser.parseInstruction(xmlInstruction);
// process the instruction
} catch ( InvalidInstructionException e) {
handleError(currentInstruction, properties,
“Invalid instruction”, e);
} catch ( InstructionValidationException e) {
handleError(currentInstruction, properties,
“Validation of the instruction failed”, e);
} catch ( ProcessorException e) {
handleError(currentInstruction, properties,
“Could not process the instruction”, e);
} catch (RuntimeException e) {
handleError(currentInstruction, properties,
“System exception”, e);
}
}

In order to provide information about the exceptions and ways to handle them, a good solution is to post messages which could not be processed to an error queue with additional information such as: error message, stacktrace, processing date, etc. One could implement a JMS browser on this queue with the ability to inspect the message which failed and why they failed, based on the information which has been added while handling the unrecoverable exception. If you provide a minimum of standardized information in the original request, one could also provide the ability to repost the message! Simple, just provide the JNDI name of the queue where the message was initially posted.

If the exception could not be recovered, a good behavior is to rollback the transaction in order to retry later on. If a message could not be processed after some time, it becomes a poison message and will be sent as a result to an error queue. A good practice in this case is to configure the system so that this error queue is the same as the one used for recoverable exceptions (With JBoss, you need to define a new invoker-proxy-binding and configure your MDB to use it, check this page for more details).

This architecture allows you to see recoverable exceptions and unrecoverable exceptions! Moreover, if the exceptions were linked to an external problem which has been solved meanwhile, you can simply repost all messages in order to process them.

In this tutorial, I am trying to explain to you how easy you could monitor, configure and manage your Java application with JMX. A good starting point is available at Wikipedia.

Basically, a JMX domain contains MBeans, which are Java objects exposing attributes and operations. Namely, an MBean could allow you to configure your application or watch the server state and fire specific actions if necessary.

To me, JBoss provides the cleanest implementation of the JMX specification. Namely, it provides a base MBean class, ServiceMBeanSupport, which allows you to implement a JMX service very easily.

This helper class provides callback methods linked to the lifecycle of your component:

• create the service
• start the service
• stop the service
• destroy the service

Here is a very naive implementation:

public class MyFirstService extends ServiceMBeanSupport
implements MyFirstServiceMBean {

protected void destroyService()
throws Exception {
logger.info(”Destroying service[”+getClass().getName()+”]”);
}
}

Note that each and every MBean needs to implement an interface which exposes the attribute(s) and operation(s) you can invoke on it. Note also that the MyFirstServiceMBean interface is empty and extends ServiceMBean which exposes already the lifecycle methods.

Attached, you can find the full source for the project and also a built version. Drop the jar file in your JBoss installation (server/default/lib propably) and put the following my-first-service.xml file in the deploy directory (server/default/deploy) of your server:

< ?xml version="1.0" encoding="UTF-8"?>

name=”nicoll.net:service=MyFirstService”>



Note that the file must end with -service.xml for it to be recognized by the JBoss deployer.

Here you go, you have deployed your first JMX service. Now you can search on the JBoss’s jmx console or web console for the nicoll.net domain and the service MyFirstService.

The english translation of Tarja’s press conference is available here.

I have setup recently a Gallery instance on the nicoll.net domain.

Nice, easy to install, easy to use and free! This application is truley complete, almost anything you would think of is available. By the way, if you want to see some nice pictures of us, let me know.

Well, at first I could not believe it but they did it.

dns.be now provides a .be domain to you for free. The purpose of this is to increase the number of belgian domains on the Internet. OVH is a partner of the operation and provides a 1000Gp for free for any belgian citizen.

Well, well, well. Nice! Domains are so hard to find these days (nicoll.net for instance was quite hard to get). I blame the poor guy in search for a .be domain.

Edit following a comment: if forgot to mention that it was free for one year. After this period, you have to pay the registration of your domain (around 8€ per year). That said, if you register with OVH the hosting is free at will, provided the domain remains at OVH. This is not specified on their web site but if you browse their forum a bit, you will find the information

As we said in my region and probably somethere else in the world, I’m “une guerre en retard” which means that I am talking about something which happened quite a while ago.

Well, sorry, I am not (that) a nerdzz. My sweet girlfriend just told me that Nightwish has fired her singer, Tarja in a letter the band gave her after their last show. By the way, one of the links above might be down soon

Tarja which was at the time of writing in Argentina, replied in a letter available in the forums.

I don’t want to tell much about the letters, except that the first one seems much more motivated. It seems that Nightwish will go without Tarja, I wonder if that will actually give any result.

Wait & See…

Backward compatibility is really an issue in computer software development theses days. And on both sides … Well I would say only one actually but let’s try to be fair.

On the dev side (mine), ensuring backward compatibility is sometimes sooOoo painful (and so easy to forget). Wanna a proof of that?

Sun which is definitely a big figure of the Java world has made a funny non backward compatibility in its J2EE specs between version 1.3 and 1.4. In the deployment descriptor of an EAR file, one could specify a description and display-name. Those elements are specified as first elements of the application.xml file.

In J2EE 1.3, one must write (to comply with the J2EE 1.3 DTD):