Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Running JBoss 5
As in my previous article on JBoss 5, you need to download and install three items of software to run the supplied code:
- Apache Ant
- JDK v1.5
- JBoss 5
Listing 1 illustrates the version of Ant I used for this article (make sure that Ant is in your system path), followed by the version of JDK I used.
Listing 1 Apache Ant and JDK versions used.
C:\java\jboss-5.0.0.GA\bin>ant -version Apache Ant version 1.7.1 compiled on June 27 2008 C:\java\jboss-5.0.0.GA\bin>java -version java version "1.5.0_17" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_17-b04) Java HotSpot(TM) Client VM (build 1.5.0_17-b04, mixed mode, sharing)
To run the example code, you need two DOS consoles—one to run JBoss and the other to run the client code. A handy way to do this is as follows:
- Open one DOS console.
- Set the two required environment strings—JAVA_HOME and JBOSS_HOME.
- Run the command start.
The start command clones the first DOS console and creates a copy with all the same environment settings. Of course, you can set the environment variables through the control panel, but I generally prefer to set them up as I go. This has the merit of avoiding clutter.
Once you've run the above steps, you can then run JBoss 5 by changing to the bin folder and executing the following command:
C:\java\jboss-5.0.0.GA\bin>run
Notice that I use a directory path with no spaces. Once you run this command, you should see a ton of console messages. If you're running Windows Firewall, you may see a message like the one in Figure 1.
)
Figure 1 Windows Firewall doing its job.
Just click Unblock to allow the JDK binary to run. If all is well with your setup, you should then see a successful message at the end of the console, as shown in Listing 2.
Listing 2 Successful JBoss 5 startup.
12:02:58,609 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080 12:02:58,750 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009 12:02:58,765 INFO [ServerImpl] JBoss (Microcontainer) [5.0.0.GA (build: SVNTag= JBoss_5_0_0_GA date=200812041714)] Started in 3m:2s:484ms
If you've managed to get this far without incident, you're ready to run the client. As in the previous article, this is a three-step process:
- Build.
- Deploy.
- Execute.
Let's see how to do this.
Code Build
The code is built simply by opening a DOS console in the folder containing the Ant script: build.xml. The DOS console is the second console I mentioned earlier. In order to run correctly, you need the following:
- Ant in the build path
- JAVA_HOME defined
- JBOSS_HOME defined
To check whether you're ready to build the code, run the following handy command:
ant –p
If all is well, you should see something like Listing 3.
Listing 3 Ant build targets.
Buildfile: build.xml Main targets: Other targets: clean clean.db compile ejbjar prepare run.client Default target: ejbjar
Listing 3 shows all the targets contained in the build file.
The default Ant target is executed simply by running the ant command with no parameters. This command also deploys the code into JBoss 5. Let's try these two important steps now.
Code Deployment
The code is built and deployed using the following simple command:
ant
If this command is successful, you should see a message to that effect in the DOS console. You should also see a successful deployment in the JBoss 5 DOS console. Look for messages such as the ones in Listing 4.
Listing 4 Successful deployment in JBoss 5.
12:48:30,953 INFO [SchemaExport] Running hbm2ddl schema export
12:48:30,968 INFO [SchemaExport] exporting generated schema to database
12:48:30,968 INFO [SchemaExport] schema export complete
12:48:30,968 INFO [NamingHelper] JNDI InitialContext properties:{java.naming.factory.initial=
org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces}
12:48:31,234 INFO [SessionSpecContainer] Starting jboss.j2ee:jar=cardsrus.jar,name=CardShopBean,service=EJB3
12:48:31,234 INFO [EJBContainer] STARTED EJB: com.cardsrus.cardshop.CardShopBean ejbName: CardShopBean
12:48:31,265 INFO [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
CardShopBean/remote - EJB3.x Default Remote Business Interface
CardShopBean/remote-com.cardsrus.cardshop.CardShopRemote - EJB3.x Remote Business Interface
The really important items in Listing 4 are at the end, related to the deployment of the EJB and the registration of the code in JNDI. Notice also the message STARTED EJB in Listing 4. This means that our EJB is deployed on JBoss and ready for business. Think of this as a little server application waiting for service requests.
Now we can run the client code. For simplicity, the deployed code already includes the interceptor logic. Before I describe that, let's just run the client code to make sure that everything is working correctly.
Running the Client Code
The client code is executed using another Ant target:
ant run.client
Listing 5 demonstrates a successful run.
Listing 5 A successful run of the client code.
ant run.client
Buildfile: build.xml
prepare:
compile:
ejbjar:
run.client:
[java] Greeting card name: Early Easter Greetings from Terry Dactyll
[java] Greeting card colour: 1
BUILD SUCCESSFUL
Total time: 9 seconds
In Listing 5, we see that a greeting card has been received! That's the client end, but what happens on the server side?
Server Side
If the interceptor code runs successfully, you should see something similar to Listing 6.
Listing 6 Successful interception.
com.cardsrus.cardshop.CardShopBean.flushGreetingCard() 13:57:38,375 INFO [STDOUT] Now at the beginning of the interceptor method public void com.cardsrus.cardshop.CardShopBean.createGreetingCard(com.cardsrus.domain .GreetingCard) startTimeSnapshot 1236693458375 13:57:38,390 INFO [STDOUT] Now at the end of the interceptor method public void com.cardsrus.cardshop.CardShopBean.createGreetingCard(com.cardsrus.domain.GreetingCard) endTimeSnapshot 1236693458390 13:57:38,390 INFO [STDOUT] Method public void com.cardsrus.cardshop.CardShopBean. createGreetingCard(com.cardsrus.domain.GreetingCard) time taken: 15 milliseconds
What's going on in Listing 6? It's the interceptor code in action, and it's finally time to look at it.
Interceptor Logic
The whole idea of interceptor code is the ability to insert new code inside the execution of existing code. This sounds complicated, but it isn't. Listing 7 shows the code location into which we want to insert some new code.
Listing 7 Code we want to intercept.
public void createGreetingCard(GreetingCard greetingCard)
{
manager.persist(greetingCard);
}
I basically want this code to change to something like Listing 8.
Listing 8 Intercepted pseudo-code.
public void createGreetingCard(GreetingCard greetingCard)
{
// Some new code here
manager.persist(greetingCard);
// And more new code here
}
The way we engineer this is by creating an interceptor class as in Listing 9.
Listing 9 The interceptor class.
public class ExecutionProfiler
{
@AroundInvoke
public Object profile(InvocationContext invocation) throws Exception
{
long startTimeSnapshot = System.currentTimeMillis();
System.out.println("Now at the beginning of the interceptor method " +
invocation.getMethod() + " startTimeSnapshot " + startTimeSnapshot);
try
{
return invocation.proceed();
}
finally
{
long endTimeSnapshot = System.currentTimeMillis();
long executionTime = System.currentTimeMillis() - startTimeSnapshot;
System.out.println("Now at the end of the interceptor method " +
invocation.getMethod() + " endTimeSnapshot " + endTimeSnapshot);
System.out.println("Method " + invocation.getMethod()
+ " time taken: " + executionTime + " milliseconds");
}
}
}
The best way to think about Listing 9 is to look at the comments in Listing 8. Notice the try statement in Listing 9? This code roughly equates to the Listing 8 code manager.persist(greetingCard). The rest of the code in Listing 9 occurs around the execution of manager.persist(greetingCard).
Look back at the console output in Listing 6. You can match the Listing 6 console output to the Listing 9 calls to System.out.println. Why might this be useful? It's useful because we can insert any code we like in the ExecutionProfiler class. An example of such code might be security authorization. The key point is that such code doesn't appear anywhere else outside the ExecutionProfiler class. In other words, we keep the code in the business logic and entity classes (and the other parts of the source code) completely clean. This is the power of interceptor code.
Now, how do we remove our code from JBoss?