Dynamically change Session/Message Driven Bean parameters

When an EJB3 Session Bean or a Message Driven Bean is created, it is assigned some basic parameters such as Max Pool Size, Timeout, Max Session Size etc. Such parameters are pre-configured with default values in ‘ejb3-interceptors-aop.xml‘ file available in $JBOSS_HOME/server/$Profile/deploy folder.

As you will open the file, you will find that the parameters are available for Session Bean are as following,


and for Message Driven Bean as following,


as you see, both the beans have Pool annotation configuration is given. If you want to change the maxSize, timeout or pool type to ThreadLocalPool or StrictMaxPool, you can change the configuration easily in this file. This will change the parameters of all the beans.

******** But there’s a problem!!! *******

This configuration is applied to every single bean deployed in your EJB container. Consider, you have 10000 session beans deployed in the container and  one of your session beans requires to have a very big pool maxSize as 1000 due to heavy request to it. The immediate thing you would do is to change the maxSize to 1000 in above file. Wait… wait… what are you doing??? There are 10000 beans and 1000 maxSize per bean… so it totals to 10000000 threads!!! I doubt that your server will survive.

Well, to a solution to this problem, add the @Pool annotation in the required session bean itself only and set the maxSize to 1000 and keep the default configuration unchanged in ‘ejb3-interceptors-aop.xml‘.


By setting the maxSize in this Session Bean, it will override the default configuration of ‘ejb3-interceptors-aop.xml‘ and assign the new maxSize to this session bean only.

******** But wait…. again there’s a problem!!! *******

Consider you have released this well set session bean on production environment and you found out that you are required to change the maxSize to 5000 instead of 1000 due to heavy load on this session bean. Oh man.. what I’ve done… you can’t do that without changing the code and redeploying this session bean on the production environment. So, what to do???

Well, don’t be alarmed. There’s a solution to this problem. The solution is, you neither set the required maxSize in Session Bean nor change it in the ‘ejb3-interceptors-aop.xml‘. Ok, but then where and how?

Here’s how we do it:

Step-1: Create a file named ‘my-aop.xml‘ file in $JBOSS_HOME/server/$Profile/deploy folder.

Step-2: Add following domain in this file,


with setting maxSize to 5000 in this file.

Step-3: Add annotation @AspectDomain with the same name you have provided in above xml file. And remove the @Pool annotation from the bean.


That’s it!!! Now, you can change any number in the maxSize in ‘my-aop.xml‘ placed in deploy folder based on your requirement . You won’t have to give a new release of code every time you want to change the pool size. Thanks God (of JBoss)!!!

******** Aahhaan… a big relief !!! *******

Some after-notes on this,

  1. You can have any prefix of name for the aop.xml file, ie. ***-aop.xml.
  2. One limitation to this, is we will have to restart the JBoss Server to take the changes in effect. However, we will have to restart the JBoss Server anyway even if we use first two methods. So, we’re even!!!
  3. Not only the @Pool annotation, but also we can configure any annotation provided by EJB specification with this aop.xml file aspect domain approach.

Further, to demonstrate other annotations, lets have example of Message Driven Bean Configurations.

A simple MDB may look like this,


To enable this bean with aspect domain, remove the @Pool and @ActivationConfigProperty annotations from the MDB and add the @AspectDomain annotation as following,


And add the domain entry with the annotations for this MDB as following in ‘my-aop.xml‘ which is already there in your deploy folder.


You can put as many <domain> entries as you can in one file, or you can create separate ***-aop.xml for different beans. Choice is yours.

Life was never been so easy!!!!

‘HASingleton’ Cluster Deployment Service with ‘PreferredMasterElectionPolicy’ Configuration

A cluster deployment service can be of various types. Today we are going to discuss  on one of its type, HASingleton cluster deployment service.

An HASingleton is a service which is deployed on multiple nodes on a cluster, but provides its service only on one of the nodes. The node which is running the singleton service is called the Master NodeWhen the master fails or is terminates, another node is elected to be a Master Node from the remaining nodes in the cluster, and the service is restarted on the new master. The remaining nodes are generally called Stand by Nodes or Slave Nodes.


JBoss provides mainly 2 election policies:

1. HASingletonElectionPolicySimple

The Simple election policy selects a master node based the relative age. The required age is configured in the position property, which is the index in the list of available nodes where,

position = 0 – refers to the oldest node (the default)

position = 1 – refers to the 2nd oldest etc.

Position can also be negative to indicate the youngness. Imagine the list of available nodes as a circular linked list.

position = -1 – refers to the youngest node

position = -2 – refers to the 2nd youngest node etc.

  <property name="position">-1</property>

2. PreferredMasterElectionPolicy

Sometimes you need a specific node to be the master node whenever available. The Preferred Master election policy does this job. This ppolicy extends HASingletonElectionPolicySimple, allowing the configuration of a preferred node. The preferredMaster property, specified as host:port or address:port, identifies a specific node that should become master, if available. If the preferred node is not available, the election policy will behave as described above.

  <property name="preferredMaster">server1:12345</property>

We will dig more on PreferredMasterElectionPolicy configuration with JBoss 5.x. Configuration steps are as below,

Step-1: Open the file ‘deploy-hasingleton-jboss-beans.xml‘ available in $JBOSS_HOME/server/$Profile/deploy/cluster folder and add the following bean,

<bean class="org.jboss.ha.singleton.PreferredMasterElectionPolicy" name="HSPreferredMasterElectionPolicy">
  <property name="preferredMaster"></property>

Where. is the IP Address and 1299 is the JNP Port. Replace IP and Port respective to your environment.

And, add the following property to HASingletonDeployer bean,

<property name="electionPolicy"><inject bean="HSPreferredMasterElectionPolicy"/></property>

For example,

<bean name="HASingletonDeployer"


exposedInterface=org.jboss.ha.singleton.HASingletonControllerMBean.class, registerDirectly=true)</annotation>

<!-- Have the BarrierController that listens for our JMX
notifications start first. -->

<property name="HAPartition"><inject bean="HAPartition"/></property>
<property name="target"><inject bean="HASingletonProfileManager"/></property>
<property name="electionPolicy"><inject bean="HSPreferredMasterElectionPolicy"/></property>
<property name="targetStartMethod">activateProfile</property>
<property name="targetStopMethod">releaseProfile</property>

<!-- whether to register thread context classloader for the RPC handler, default is false -->
<!--<property name="registerThreadContextClassLoader">false</property>-->

<!-- Whether the singleton should be restarted (i.e. invoke the TargetStopMethod and then the
TargetStartMethod) if a cluster merge occurs while this node is the singleton master.
A cluster merge means there may have been more than one singleton master during the period
when communication between some or all of the nodes in the cluster was disrupted; hence the
surviving master may not be aware of state changes made by another master. Restarting the
singleton gives it a signal that it should refresh its internal state from any external
By default this is set to true.
<property name="restartOnMerge">true</property>


Step-2: Deploy an HA Singleton service in the deploy-hasingleton folder.

Step-3: Start two or more nodes in the cluster partition.

Now, you would see that the HASingleton service would be deployed on the preferredmaster node!

Getting JBoss Server Info under the hood without touching the server box

Conversation:  [Boss vs. JBoss Geek ]

Boss: Hey buddy, you know that guy BOB at onsite… he installed the JBoss server on production box. I need some info on that. Can you grab some for me?

JBoss Geek: What sort of info you need boss?

Boss: Well, not much. Can you just check for me which JBoss Version BOB has installed on production server? On which path? Hey, also check me on which Ports Set it is installed on? And yea, configuration name too if you don’t mind. Also, don’t forget the Bind Address along with the UDP Group Address. And oh yea, I know you won’t forget to check which Java Version it is running on along with the OS Version. That’s it buddy!

JBoss Geek: Ok ya sure boss. Not much. I can check these things for you. Please share me the production server credentials to access the JBoss Server for getting details you’ve asked for.

Boss: Oh man, you’re kidding me, right? Why do you think they’d give us the production server access!! We don’t have production server access buddy. All we have is just the access to our application via browser. But, You’re a JBoss Geek, an important asset of organization. Use your Magic Wand. I’m sure you’ll grab the info for me, right buddy? Inform me once done, alright… see ya !!!

JBoss Geek: Ohkk, Boss!!! :-(

Oops, the geek is stuck… literally I mean!!! He was always used to make his hands dirty on the ground for grabbing such info by accessing the physical location of JBoss Installation, Configurations, Logs etc. He ain’t got no access to either of these now. Just the browser by which he can access the deployed application. What to do??? Well, its time for the geek to air the Magic Wand!!! Let’s help the geek!!!

Well, its not always that you’ve got to make your hands dirty to get these info. JBoss publishes all the meta info. on the management console called ‘jmx-console‘. The JMX Console is accessible via browser using the IP Address and HTTP Port Number of JBoss where your web application is running.  The JMX Console is accessible as following URL Pattern:


All the meta information about JBoss Server is available on JMX Console under ‘jboss.system’ domain.


Once you click on the ‘jboss.system‘ domain, you’ll see the management services under this domain.


Now, let’s sum up all the information the Boss wanted:

  1. JBoss Version
  2. JBoss Path
  3. Ports Set
  4. Configuration Name
  5. Bind Address
  6. UDP Group Address
  7. Java Version
  8. OS Version

So, this is all information the Boss wanted. Yes, ‘not much‘!!! :D

Let’s get all the things one by one by using either of the Management Services shown in above screen.

PS: I have pixelated some private info which I don’t want to disclose for my JBoss server in screenshots as following.


1. JBoss Version:

Access Path: jmx-console -> type=Server -> VersionNumber


Oh yeah, enjoying!! Let’s hit another.


2. JBoss Path:

Access Path: jmx-console -> type=ServerConfig -> JBossHome



3. Ports Set

Access Path: jmx-console -> service=ServiceBindingManager -> ServerName



4. Configuration Name:

Access Path: jmx-console -> type=ServerConfig -> ServerName



5. Bind Address:

Access Path: jmx-console -> type=ServerConfig -> BindAddress



6. UDP Group Address:

Access Path: jmx-console -> type=ServerConfig -> UdpGroup



7. Java Version:

Access Path: jmx-console -> type=ServerInfo -> JavaVersion



8. OS Version:

Access Path: jmx-console -> type=ServerInfo -> OSVersion (also OSName for OS Name)


Yeahh, that’s cool… isn’t it!!!

So, not only those info. asked by Boss can be found, but also there’s a plenty of other meta info. you can find under the hood on jmx-console. Quite powerful… yes we aired the Magic Wand and spared some time for checking out the social network!!!

Boss: Hey buddy, got the info??

JBoss Geek: Hmm.. yes, boss… the info. is blah blah blah @#%#$^#%$^.

Boss: Okay, cool… hope you didn’t have much problem to grab this info man!

JBoss Geek: Nah, ‘not much‘!!! ;-)

Custom Library Management for specific JBoss Server Instance

In one of our previous post, we have discussed about the Directory Structure of JBoss. There is a specific directory called ‘lib‘ in each JBoss Server Instance (JBoss Server Profile).


The ‘lib‘ directory consists of JAR files which is specific to given JBoss Server Profile (or Instance). It is very convenient to place all the libraries related to given profile. But the only problem with this is, when we add up huge number of JAR files in this folder, it becomes hard for us to manage library files.

Consider I have an e-commerce application I deployed on JBoss Profile named ‘default‘. I have multiple modules under this application such as,

  • Sales
  • Marketing
  • Order Management
  • CRM

and so on.

And I have many supporting 3rd party libraries for each of these modules. What I would do as a laymen, I would place all the libraries under the ‘lib‘ directory. But, this will cause the Spaghetti Artifacts problem. Means, libraries of all modules are placed under one directory. Everything’s together… Mixed… like Spaghetti!!! This becomes hard to manage if I want to keep track of all the libraries I have added for each modules.

Well, not to be alarmed!!! We have a luxury in JBoss to manage libraries under given profile more custom way. Following are the steps:

Step-1: Go to ‘lib‘ directory under your JBoss Server Profile (here default).


Step-2: Create module wise directories under lib.


Step-3: Place your module specific libraries under each module directory created.


Ok, we’re good so far. We have placed segregated JAR files module wise for each modules. But, the story doesn’t end here. JBoss will not consider all the .jar files under lib directory recursively unlike deploy folder does unless you ask JBoss to consider these jar file explicitly in classpath. Well, for this configuration, follow the important Step-4.

Step-4:  Go to jboss-service.xml file available in conf folder at $JBOSS_HOME\server\default\conf. The classpath of these custom modules libraries are configured in this file as following:


Note the classpath entries added for each module (line no. 19-22) in above file. Here, the library classpath already exists for lib directory (line no. 15). Here, the JBoss Property ${jboss.server.lib.url} consists of path lib folder of ‘this‘ server instance.

We just have extended the classpath further by adding path of sub-directory under this directory by padding module name with this JBoss Property. 

After this configuration, you are required to restart the instance. This is it!!!

Yeaahh, Life was never been so easy!!! :-)

Book Review: Drools JBoss Rules 5.X Developer’s Guide

Dear Folks,

Recently, I have been studying a newly published book on JBoss Drools Business Rules Framework named “Drools JBoss Rules 5.X Developer’s Guide“. I found this book very good, so decided to post review of this book on this blog.

This book is from Packt Publishing and written by Michal Bali.  He is a freelance software developer having more than 8 years of experience working with Drools and various Java/JEE Technologies and he’s an active member of the Drools community.


The book is about Drools framework provided by JBoss Community. Drools is a Java based Business Rules Framework. Consider you are having Billing System in which you have multiple business cases on Bill generation. For example, if a customer is having category as “Gold“, apply discount 30%. If a customer is having category as “Gold” and is registered in system for more than 3 years, apply additional 10% loyalty discount. If a customer is a senior citizen, exempt some percentage of Tax etc.

In above example case, generally we write number of If… else blocks in the code to filter the conditions on given rules. But what if the system is very huge and having enormous amount of such rules. Once the rules are hard-written in code and if any changes may require in rules, you may have to change the code, build the system and release the maintenance patch to the user, which is a very hectic and time consuming process.

To get rid of such problems, Business Rules Frameworks are there using which you can configures rules in some rule configuration files, and you can alter the rules at  run time without making any single changes in the code. Drools is one of the widely used open source rule engine by JBoss Community.

This book gives good insight on Drools framework by JBoss Community. The book mainly consists of 12 Chapters full of easy to understand theories and rich examples. We will quickly have brief reviews on each chapters:

Chapter 1: Programming Declaratively

This chapter consists of basic introduction of the business rules and business process domain. The need of business rules and why standard solution fails if the number of rules are huge and rules are complex. Also, the history of Drools is mentioned in this chapter.

Chapter 2: Writing Basic Rules

This chapter shows the basics of working with the Drools rule engine, Drools Expert. It shows the simple examples and explained step-by-step. Also, it mentions the development environment setup, writing a simple rule and then executing it. The chapter goes through some necessary keywords and concepts that are needed for more complex examples.

Chapter 3: Validating

This chapter explains the example of a banking domain. This example will be the basis for examples later in this book. The chapter then goes through an implementation of a decision service for validating this banking domain. A reporting model is designed that holds reports generated by this service.

Chapter 4: Transforming Data

This chapter explains how Drools can be used for doing complex data transformation tasks. It starts with writing some rules to load the data, continues with the implementation of various transformation rules. Also, it puts together the results of this transformation. This chapter shows how we can work with a generic data structure such as a map in Drools.

Chapter 5: Creating Human-readable Rules

This chapter focuses on rules that are easy to read and change. Starting with domain-specific languages, the chapter shows how to create a data transformation-specific language. Also, it focuses on decision tables as another more user friendly way of representing business rules. An interest rate calculation example is shown. And finally, this chapter introduces the JBoss jBPM as a way of managing the rule execution order.

Chapter 6: Working with Stateful Session

This chapter talks about executing the validation decision service in a stateful manner. The validation results are accumulated between service calls. This shows another way of interacting with a rule engine. Logical assertions are used to keep the report up-to-date. Moreover, various ways to serialize a stateful session are discussed in this chapter.

Chapter 7: Complex Event Processing

This chapter goes through various features such as events, type declarations, temporal operators, sliding windows, and others. Drools Fusion, another cornerstone of the Drools platform, is about writing rules that react to various events. The power of Drools Fusion is shown on a banking fraud detection system. This is a very interesting chapter.

Chapter 8: Defining Processes with jBPM

This chapter discusses into more detail about the workflow aspect of the Drools platform. It is shown on a loan approval service that demonstrates the use of various nodes in a flow. Also, the chapter talks about implementing a custom work item, human task, and a subflow etc.

Chapter 9: Building a Sample Application

This chapter shows how to integrate Drools in a real web application. You will be gone through the design and implementation of persistence, business logic, and presentation layers in this chapter. Also, all the examples written so far will be integrated into this sample application.

Chapter 10: Testing

This chapter aims to give you an idea of various ways of how to test your business logic. Starting with unit testing, integration testing through acceptance testing will be shown on the business rules management server, whis is known as Guvnor. This chapter provides useful advice on various troubleshooting techniques as well.

Chapter 11: Integrating

This chapter demonstrates the integration with the Spring framework. It describes how we can make changes to rules and processes while the application runs. It shows how to use an external build tool such as Ant to compile rules and processes. It talks about the rule execution server that allows us to execute rules remotely. It also briefly mentions support of various standards.

Chapter 12: Learning about Performance

This chapter takes us under the hood of the Drools rule engine. By understanding how the technology works, you’ll be able to write more efficient rules and processes. It talks about the ReteOO algorithm, node sharing, node indexing, and left/right unlinking. You’ll find this chapter very interesting if you are a kind of performance geek!


In summary, I would like to quote that,

This drools book is a very good step-by-step reference with practical examples. This helps specially for the beginners since the flow of the book is very structured and intuitive. I would recommend to grab this book if you are willing to dig deep into Drools framework. A perfect guide for the drools developers!!!

You can grab the copy of this book on Packt Publishing website at


Share if you have liked this review. Enjoy!

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

In our previous post, we have discussed about the directory structure of JBossAS-5.x where we have had a glance on the ‘client‘ directory of JBoss. The ‘client‘ directory consists of all the client libraries required to make communication with the server.

Consider, you have an EJB application deployed on your JBoss AS Server. You want to invoke a method of the EJB 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 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 the 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 appears as following,


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


If you want 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 JVM, this file will look up for 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 questioned yourself throughout the read that 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???

To answer to the question, 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!

Understanding JBoss Directory Structure

JBoss has very very simple and modular directory structure. You can mold it very easily according to your needs. The pattern of directory structure follows as per following categories,

  • JBoss AS 3.x – 4.x Directory Structure
  • JBoss AS 5.x – 6.x Directory Structure
  • JBoss AS 7.x – Onward Directory Structure

We are going to discuss the structure of JBoss AS 5.x – 6.x. The directory structure of [JBoss AS 5.x - 6.x] is almost similar to [JBoss AS 3.x - 4.x]. However, the major update in [JBoss AS 5.x - 6.x] family is, its refactored stack of Microcontainer.

Moreover on this, The [JBoss AS 5.x - 6.x] family implements EJB3 Specs, runs on JDK6, supports replaceable Messaging broker such as HornetQ Messaging etc.

The directory structure of JBoss AS 7.x is enormously transformed. We will discuss about JBoss AS 7.x family in our upcoming posts. For an immediate post, I am going to write a dedicated post on the difference between the [JBoss AS 3.x - 4.x] and [JBoss AS 5.x - 6.x] family soon.

Lets check out the structure of JBoss AS 5.x – 6.x family,


Description of each directory is as following,

  • bin: It contains all the start up, shut down scripts for running JBoss Server.
  • client: It contains all the libraries to run client applications.
  • common/lib: It contains all the common or shared libraries used by all the profiles of JBoss Server.
  • docs: It contains all the definitions of DTDs and XSDs which tells how your xml structure should be, which part of JBoss server configuration. E.g. Datasource XML Files, deployment discriptor xml files etc.
  • lib: It contains all the necessary library files required for JBoss bootup. It also contains  microcontainer implementation libraries in this directory.
  • server: This is the heart of JBoss application server. It contains various pre-built server configurations, or let’s call it “profile“. A profile is nothing but the replica of a JBoss Server. Each profile under sever directory is itself a server or an application server engine that is responsible for running all the containers or specs implementations. Each profile follows similar sub-directory structure.  Server directory contains following pre-built profiles by default,

default – The Basic JBoss configuration profile which contains default set of services required for ready-to-use JavaEE application deployment.
all – This is a full Java EE compliant profile having cluster services enabled profile having clustering configurations of JBoss.
standard – The standard JavaEE 5 compliant profile.
web – Lightweight web container profile which is Java EE 6 Web Profile compliant.
minimal – This is a very minimal configuration of JBoss profile which hardly contains basic Java EE services. E.g. it does not contain any web container, EJB container or any JMS broker. This is a rarely used profile.

Each profile inside server directory follows similar sub-directory structure as following,

  • conf: It contains all the configuration files related to the current profile. E.g. logging, ports config, container config, jndi config etc.
  • data: It contains all the extracted artifacts of deployed application archives.
  • deploy: This is the place where you can deploy your application. Along with your application, the core services of JBoss are also deployed under this directory. E.g. Web container service, http invoker service, admin console service, jmx console services etc.
  • deployers: It contains all the deployers configurations which defines how JBoss core artifacts should be deployed.
  • lib: Library files supporting current profile/application.
  • log: All the application and JBoss services logs are logged in this directory.
  • tmp: It holds all the temporary data created by application container.
  • work: It holds all the temporary data created by web container.

In nutshell, if we compare the structure of JBoss AS with an analogy, then it is something very much similar to a Car,


The server profile is the primary server similar to engine in a car.

The scripts in bin directory helps in start/stops and controlling which is similar to car key and the starring of a car.

The other supportive artifacts such as docs, lib etc helps in running the server which is similar to car wheels.

What is JBoss AS?

We’re going to start off by introducing JBoss AS and its basic details. JBoss is an Open Source Community Project from Red Hat Inc. JBoss, which is now known as “WildFly“, is an Java EE based Application Server that runs on various JVMs. JBoss is not only implemented in Java, but also runs on Java.

JBoss implements the Java Server and Specification of Java EE. The primary task of JBoss Application Server is to allow Java EE based applications to host and run on its platform. In tech language, the alternative term for “host” is to “deploy“.

In nutshell, we deploy Java EE based Applications on JBoss Application Server which implements specs of Java EE.

Latest version of JBoss AS currently available is 7. Earlier of our articles/tutorials will be based in JBoss AS 5 or 6.

JBoss comes in two editions. One is community edition which is called JBoss AS, another is enterprise edition JBoss EAP (Enterprise Application Platforms).

The community edition is fast developing by the community users to the community. It is more suitable for advanced developers who wants to try something new.

While the enterprise edition is extensively tested and stability is guaranteed by Red Hat. JBoss EAP is not just an application server, but a stack of various other programs as well other than application server. Red Hat provides professional support on enterprise edition. It is more suitable for production environment.

The comparative analysis of JBoss Community and JBoss EAP is stated by Red Hat as following,

JBoss Community vs JBoss EAP

For more information on JBoss Application Server, visit http://www.jboss.org/jbossas

Image Source: http://www.redhat.com/rhecm/rest-rhecm/jcr/repository/collaboration/sites%20content/live/redhat/web-cabinet/static-files/images/JBoss-Comparison-Table-big.png