DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Using SQS With JMS for Legacy Applications
  • Javac and Java Katas, Part 2: Module Path
  • Javac and Java Katas, Part 1: Class Path
  • Ways To Reduce JVM Docker Image Size

Trending

  • Power BI Embedded Analytics — Part 2: Power BI Embedded Overview
  • *You* Can Shape Trend Reports: Join DZone's Software Supply Chain Security Research
  • Scalable System Design: Core Concepts for Building Reliable Software
  • Accelerating AI Inference With TensorRT

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

By 
Hushen Savani user avatar
Hushen Savani
·
Dec. 29, 13 · Interview
Likes (0)
Comment
Save
Tweet
Share
6.4K Views

Join the DZone community and get the full member experience.

Join For Free

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

JAR (file format)

Opinions expressed by DZone contributors are their own.

Related

  • Using SQS With JMS for Legacy Applications
  • Javac and Java Katas, Part 2: Module Path
  • Javac and Java Katas, Part 1: Class Path
  • Ways To Reduce JVM Docker Image Size

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: