Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




2.2. Server Configurations

Fundamentally, the JBoss architecture consists of the JMX MBean server, the microkernel, and a set of pluggable component services - the MBeans. This makes it easy to assemble different configurations and gives you the flexibility to tailor them to meet your requirements.
You don’t have to run a large, monolithic server all the time; you can remove the components you don’t need (which can also reduce the server startup time considerably) and you can also integrate additional services into JBoss by writing your own MBeans. You certainly don’t need to do this to be able to run standard J2EE applications though. Everything you need is already there.
You don’t need a detailed understanding of JMX to use JBoss, but it’s worth keeping a picture of this basic architecture in mind as it is central to the way JBoss works.
The JBoss Enterprise Application Platform ships with four different server configurations. Within the JBOSS_DIST/jboss-as/server directory, you will find four subdirectories: minimal, default, production and all - one for each server configuration. Each of these configurations provide a different set of services. The production configuration is the one used if you don’t specify another one when starting up the server.
has a minimal configuration—the bare minimum services required to start JBoss. It starts the logging service, a JNDI server and a URL deployment scanner to find new deployments. This is what you would use if you want to use JMX/JBoss to start your own services without any other J2EE technologies. This is just the bare server. There is no web container, no EJB or JMS support. This is not a J2EE 1.4 compatible configuration.
is a base J2EE 1.4 server profile containing a default set of services. It has the most frequently used services required to deploy a J2EE application. It does not include the JAXR service, the IIOP service, or any of the clustering services. Please note that although this configuration is called "default", the actual default configuration for the server is the "production" configuration.
on the other hand has all the services configured to launch every single component. This is a full J2EE 1.4 server profile with enterprise extensions such as Clustering and RMI/IIOP.
is based on the "all" profile, tuned for production; with log verbosity reduced, deployment scanning every 60 seconds, and memory usage tuned to accomodate production deployment requirements, among other things. This is the configuration that will be used by the server when it is started, if no other configuration is specified.
If you want to know which services are configured in each of these instances, look at the jboss-service.xml file in the JBOSS_DIST/jboss-as/server/<instance-name>/conf/ directory and also the configuration files in the JBOSS_DIST/jboss-as/server/<instance-name>/deploy directory.
[vsr]$ls server/default/conf 
jbossjta-properties.xml   standardjbosscmp-jdbc.xml
jboss-log4j.xml          login-config.xml  standardjboss.xml
jboss-minimal.xml        props             xmdesc
jboss-service.xml        standardjaws.xml


The production configuration is the one used if you don’t specify another one when starting up the server.
To start the server using an alternate configuration refer to Section 2.3.2, “Start the Server With Alternate Configuration”.

2.2.1. Server Configuration Directory Structure

The directory server configuration you’re using, is effectively the server root while JBoss is running. It contains all the code and configuration information for the services provided by the particular server configuration. It’s where the log output goes, and it’s where you deploy your applications. Table 2.2, “Server Configuration Directory Structure” shows the directories inside the server configuration directory (JBOSS_DIST/jboss-as/server/<instance-name>) and their functions.
Directory Description
conf The conf directory contains the jboss-service.xml bootstrap descriptor file for a given server configuration. This defines the core services that are fixed for the lifetime of the server.
data The data directory is available for use by services that want to store content in the file system. It holds persistent data for services intended to survive a server restart. Serveral JBoss services, such as the embedded Hypersonic database instance, store data here.
deploy The deploy directory contains the hot-deployable services (those which can be added to or removed from the running server). It also contains applications for the current server configuration. You deploy your application code by placing application packages (JAR, WAR and EAR files) in the deploy directory. The directory is constantly scanned for updates, and any modified components will be re-deployed automatically. This may be overridden through the URLDeploymentScanner URLs attribute.
lib This directory contains JAR files (Java libraries that should not be hot deployed) needed by this server configuration. You can add required library files here for JDBC drivers etc. All JARs in this directory are loaded into the shared classpath at startup.
log This is where the log files are written. JBoss uses the Jakarta log4j package for logging and you can also use it directly in your own applications from within the server. This may be overridden through the conf/ log4j.xml configuration file.
tmp The tmp directory is used for temporary storage by JBoss services. The deployer, for example, expands application archives in this directory.
work This directory is used by Tomcat for compilation of JSPs.
Table 2.2. Server Configuration Directory Structure

  Published under the terms of the Open Publication License Design by Interspire