59Fixing common deployment errors

For those of you not inclined to take such drastic measures, the jarFinder utility is for

you. You can use it to search through a directory of JAR files (including subdirecto-

ries) looking for a class, a property, or any other kind of file, with a given name.

You can download the source for jarFinder at http://www.isocra.com/articles/

jarFinder.php. The files also appear in the source for this book. Once you download it, unzip it and build it using the provided build.xml Ant script. The resulting class files appear in the classes subdirectory, which you must include in the class path.

Here’s an example of running the utility to locate the org.jboss.aop.advice.Inter-

ceptor class within the JBoss installation directory:

java –cp classes com.isocra.utils.jarSearch.DirectorySearcher

➥ $JBOSS_DIR org.jboss.aop.advice.Interceptor.class

Once you locate the JAR file that contains the class, you should include it in your

application. If you have a client application with this problem, then you should

include the JAR file in your client’s class path.

The often-overlooked root cause is that the wrong class loader is looking for the

missing class. For example, a servlet in your WAR file invokes an EJB located in a

JAR file in the EAR file that, in turn, attempts to access a class in the WAR file. The

issue here is that the classes in the EAR file don’t have visibility to the classes in the

WAR file.

The solution is fairly simple: move the JAR file to a lower level in the class visibility

hierarchy. For the example, you move the classes out of the WAR file and into the EAR

file. You might have to repackage your classes because you should keep the servlet

classes in the WAR file. Now the servlets and the EJBs have access to the classes.

A variation of this problem for a client application occurs when the text no security

manager appears, as follows:

javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jbia.SomeMissingClass (no security manager: RMI class loader disabled)]

A Google search would seem to indicate that you need to set up a security manager,

but that’s typically not necessary. Instead, the solution is to make the necessary JAR file

available in the class path for the client application.

3.3.2 Duplicate JAR files

Another common problem is including a JAR file in your application that’s already

provided in the application server’s server/xxx/lib directory (or even elsewhere, such

as the tag library JAR, jstl.jar, which is provided in the server/xxx/deploy/jbossweb.sar

directory). Sometimes this isn’t a problem, but if you get a ClassCastException, you

might look to see if you’re packaging JAR files that are already supplied by the applica-

tion server.

A variation of this problem happens when you include the log4j.jar file in your application. Then, you get the following error:

10:42:50,093 ERROR [STDERR] log4j:ERROR "org.jboss.logging.util.Only OnceErrorHandler" was loaded by [org.jboss.system.server.NoAnnotatio nURLClassLoader@1de3f2d].

10:42:50,249 ERROR [STDERR] log4j:ERROR Could not create an Appender . Reported error follows.

10:42:50,249 ERROR [STDERR] java.lang.ClassCastException: org.jboss. logging.appender.DailyRollingFileAppender

In either case, the solution is simple: remove the offending JAR file from your archive,

or define a separate class loader repository for the application.

3.3.3 Zip file errors

Archive files are in a zip file format, and the zip file classes provided by the JVM are

used to unpack such archives. A variety of exceptions are thrown when the zip file classes have problems unpacking files. These problems typically occur if an archive is being copied to the deploy directory, and at the same time, the hot deployer runs and attempts to deploy a partially copied file.

Assume you have a WAR file that’s 10 MB due to the number of JAR files you need

to include. Also assume that when you copy the file over a network to the deploy direc- tory, it takes the file 20 seconds to copy. Recall that the hot deployer runs every 5 sec- onds, so we can guarantee you that the hot deployer will attempt to deploy the file before it has been completely copied. The result—a zip file error.

A variation of this problem happens when deploying an exploded directory; all the files aren’t copied before the hot deployer runs, and you get a missing file error. But when you look for the file, there it is. Unfortunately, cursing the hot deployer does you no good.

The solution is to not copy anything into the deploy directory. Instead, copy the application package into a temporary location on the same hard drive partition as the deploy directory. Then once the copy is complete, move the package to the deploy directory. Such a move, because it’s on the same partition, is atomic.

3.3.4 Class cast exception

Class cast exceptions can be caused by a variety of problems. The most obvious is that the object you’re attempting to cast isn’t of the type you thought. You can easily deter- mine this by examining the class of the object you’re attempting to cast, either through using a debugging tool or by adding logging code to your application to print out the class of the object. But there are two other subtle causes that can take place when using an application server.

First, you might be getting an object, such as an EJB, from JNDI and then attempting

to cast the resulting object. For example, consider the following code to access an EJB:

Context ctx = new InitialContext(); MyEjb ejb = (MyEjb)ctx.lookup(“MyEjb”);

One potential problem in this code is that you used the wrong JNDI name to look up

61