What’s all that jazz about ‘jbossall-client.jar’?

In the directory structure of JBossAS-5.x ,there’s a directory named ‘client‘. The ‘client‘ directory consists of all the client libraries required to make communication with the server.

Consider a scenario where you have an EJB application deployed on your JBoss AS Server. You want to invoke an EJB method from a Client POJO (e.g., from an Eclipse Project). In that case, you are required to include all the client libraries in your project Class-path in order to invoke EJB methods on the server. There’s a special eye-catching library file in client directory named jbossall-client.jar. This file consists of all the client classes of JBoss.

Up to JBossAS-4.x, the jbossall-client.jar file was used to contain all the classes of client. Such as,

However, in JBossAS-5.x and above, this jar file does not contain any actual classes, it only contains the META-INF/MANIFEST.MF, which lists the needed dependencies against the other libraries from server’s client directory. The anatomy of this jar file is shown below,

The META-INF/MANIFEST.MF file contains the list of dependent jar files in Class-path as following,

If you want to use this jar, you must place all the listed jar files in the same directory as jbossall-client.jar in your project classpath.

The description of the readme.txt file included in jar says that,,

“ This jar file contains a classpath reference to various client jar files used by jboss client applications. Each of the jar files in the following list must available in the same directory as the jbossall-client.jar, Otherwise they will not be found by the classloader. “

This means when the jbosall-client.jar file would be loaded by the JVM, this file will look up the dependent classes from the listed jars in MANIFEST.MF. If the JVM would not find the dependent classes in the classpath, it will throw the ClassNotFoundException.

Well, there’r some hacks to get rid of such issues…

Let the Hacking begin!!! :

Hack-1: If you’re a JBoss Geek who is so sure of the minimum number of client libraries you are required to make the remote call, you can directly include those client libraries in your classpath, and exclude the jbossall-client.jar from the classpath. By this, the JVM will not cry for those dependent class files. Oh yes, you’ve got those jar file names on your fingertips. Geeky!

Hack-2: Repackage your jbossall-client.jar file. Repackaging can be done in two ways. First is, open the jbossall-client.jar archive with any free archive tool such as 7-zip or WinRar, and remove the name of jar files you don’t want from the Class-path defined at META-INF/MANIFEST.MF. And just ‘Save’ the file and close it. It will automatically repackage the jar file by injecting the modified MANIFEST.MF file.

If you don't want to use such tools, then the other way of repackaging this jar is using the jar command from Java. Use following steps to repackage this jar,

1. Copy jbossall-client.jar file from JBOSS_HOME/client and place it to some convenient directory.
   
2. Open command prompt or terminal and navigate to the directory where you have copied this file.
   
3. Make sure your JAVA_HOME environment variable is set with bin directory in PATH, else you may have to refer to absolute path of jar command while using it. 
   
4. Fire command: jar -xvf jbossall-client.jar .This will extract the content of this archive.
   
5. Now, go to extracted content and open META-INF/MANIFEST.MF, and remove the name of jar files you don't want to use. And save the file.
   
6. Go to your command prompt or terminal again and fire the command: jar -cvfM jbossall-client.jar META-INF readme.txt . This will repackage the jar file with the same name as jbossall-client.jar.
   

Now, once this jar file is repackaged, you can use this jar file in your classpath along with the dependencies manifested.

But why.. why... why....??? :

Well, you must've been asking yourself throughout the article why the heck you want to use jbossall-client.jar if you are cool enough to use other dependent jars without jbossall-client.jar at client side???

The answer to this question is: if you are not aware of the list of jar files to be included at client side, your screen will be flooded with ClassNotFoundException. And iteratively you will have to look up for those client jar files containing those class files. Hence, jbossall-client.jar provides a pretty good listing of these dependencies. Moreover, listing twenty to thirty jar files in the classpath for a client seems to be too much work on the part of your customers. Hence, I recommend the usage of this file. Sometimes people call this jbossall-client.jar file a big mess, but I find it very convenient to use it in order to impose the dependencies in a more structured way!

Source: http://www.jboss.org.in