Java Tutorial - Java Scipt :
Standalone JMS Clients
public void onMessage( Message message )
{
System.out.println( “Got “ + message );
try
{
if( message instanceof TextMessage )
{
String message_body =
( (TextMessage) message ).getText();
// -- Do something useful with the message body.
// -- We’ll use the time value that is the body
// -- of the message sent by SimplePublisher
// -- and calculate the elapsed time in secs.
double elapsed_time = ( ( new Date() ).getTime() -
Long.parseLong( message_body ) ) / 1000.0;
System.out.println(
“Message has spent “ +
elapsed_time + “ in transit.” );
}
}
catch( Exception e )
{
e.printStackTrace();
}
}
}
);
connection.start();
// --- Keep running until enter is pressed. ---
System.out.println( “Press enter to quit.” );
System.out.println( “Awaiting messages...” );
System.in.read();
session.commit();
}
catch( Exception e )
{
e.printStackTrace();
}
finally
{
try
{
if( session != null )
{
session.close();
}
}
catch( JMSException e2 )
{
e2.printStackTrace();
}
try
{
if( connection != null )
{
connection.close();
}
}
catch( JMSException e2 )
{
e2.printStackTrace();
}
}
}
}
You can compile the program with the following command:
javac -classpath .;%JBOSS_HOME%\client\jbossall-client.jar SimpleSubscriber.java
For Linux clients, replace the command with:
javac -classpath .:$JBOSS_HOME/client/jbossall-client.jar SimpleSubscriber.java
After it is compiled, try running SimpleSubscriber. As before, you’ll need JBoss to be running.
In Windows, SimpleSubscriber can be run with following command:
java -classpath .;%JBOSS_HOME%\client\jbossallclient. jar;%JBOSS_HOME%\client\log4j.jar SimpleSubscriber
In Linux, the command is:
java -classpath .:$JBOSS_HOME/client/jbossallclient.
jar:$JBOSS_HOME/client/log4j.jar SimpleSubscriber
At this point, the SimpleSubscriber should be patiently awaiting messages. In a new command shell, run the SimplePublisher program. You should get some output showing the details of the JMS message, as well as a short line on the time elapsed. At this stage, we know the basic JMS pub/sub messaging is working, so everything is configured right.
If you’re having problems with the messaging, check that JBoss is running. You can check by surfing to the JMX console at http://localhost: 8080/jmx-console. If you see a HTML page for JBoss, then you’re good to go.
Please note that the JMX module is not available if you are using the standalone JBossMQ configuration.
The code for SimpleSubscriber is very similar to that of SimplePublisher. The main addition is the anonymous inner class that serves as the incoming message handler. This is the section of code that looks like:
subscriber.setMessageListener(
new MessageListener()
{
public void onMessage( Message message )
{
....
}
}
);
Also, it uses the JMS subscriber counterparts. This is an exercise of pub/sub messaging, but PTP can be easily swapped in by substituting the appropriate PTP classes, which is an example of how the domain unification in JMS 1.1 off. Prior to 1.1, the interfaces for pub/sub were different from those for PTP. The older interface is still there, so if you want to trade off flexibility for backward compatibility, you can do so.
With the programs, our text message body is a string representation of the time. We can visually verify that the JMS message header contains an attribute called jmsTimeStamp that matches up with our calculations.
Now, let’s take a look at the JMX console and see how it fits into the JMS picture. JMX is a Java management specification that exposes MBeans, which are management components. In the JMX console, these MBeans correspond to subsystems within JBoss. Run JBoss and open a browser to show the JMX console (shown in Figure 9.1), which can be found at http://localhost: 8080/jmx-console.
As you can see in Figures 9.1 and 9.2, the JMX console has a vast array of MBeans displayed. This top-level view of the JBoss server is called the JMX Agent view. We’re interested in looking at the JBossMQ queues and topics, so let’s skip on down to the section titled jboss.mq.destination. This is where all the queues and topics are listed. Let’s take a more in-depth look at testTopic. Click on the service=Topic,name=testTopic link. We are now presented with a view of the MBean for testTopic. Here, we can see what’s going on inside the JBoss server. For example, there’s an attribute called JNDI Name with the value topic/testTopic. This is the JNDI name to which the testTopic is bound. Let’s try changing that to topic/testTopic2. Click Apply Changes, and try running the SimplePublisher program again. As you can see from the stack trace, the JNDI name has been changed, and testTopic is no longer available under topic/testTopic. Now, let’s go back and change the JNDIName back to topic/testTopic. If you run SimplePublisher again, you’ll see that everything is back to the way it was.
Let’s take a look at how we can add and remove queues and topics via the JMX console. Go back up to the top-level JMX Agent view. Now, look for the jboss.mq section. There will be a link called service=Destination
Manager. This is the MBean that controls the creation and destruction of JMS destinations. Click on the link. We changed MBean attributes before, but we also have the ability to execute MBean operations. Go to the void create
Topic() operation and type in testTopic2 for arg0, which is the name of the topic we want to create. Click Invoke, and you should see a message like Operation completed successfully without a return value.So far so good! Now, go back to the JMX Agent view and check out the jboss.mq.destination section. You should find your newly created JMS topic there. If you drill down into the MBean view for testTopic2, you’ll see that it is bound to the JNDI name topic/testTopic2 by default. The JNDI names that things are bound under can vary between J2EE application servers. In this case, JBoss uses the topic/ for JMS topics.
From our experience, developer assumptions about the JNDI naming can be the source of much wasted time and frustration, so tread carefully. The JMX console is a powerful tool, but you can also potentially make changes that disrupt the system. Use it carefully for changes. Even if you’re not making changes, the JMX console is excellent for getting information on the state of a running system.
Okay, we’ve got JBossMQ’s basic JMS functionality running. Now, let’s try using it from within the J2EE framework, namely from a servlet and then a MDB.
