JBoss in Production

This a short topic on getting JBoss ready for the Production environment, I cover such things as selecting a platform, removing unnecessary services, securing the application services, etc

Selecting a platform can be a daunting task, although costs does play a major part, you also have to decide on what JVM you want to use as well which the O/S may give you limited options.

There are a number of different JVM vendors Sun, IBM and BEA being the top three, all three implement there JVMs differently so make sure you know the difference between them, I leave you to the web to find out. One thing you should remember is try not to tie your application in to one particular vendor thus if you have to move then it should not be a major problem.

The below table details the JBoss versions and what minimum supported JVM can be used

JBoss Version Minimum JVM version required J2EE/Java EE version supported
AS 3.0 JVM 1.3 J2EE 1.3
AS 4.0 JVM 1.4 J2EE 1.4
AS 4.2 JVM 1.5 J2EE 1.4/Java EE 5
AS 5.0 JVM 1.5 Java EE 5

Running Multiple Instances

When using multiple instances you use the "-c" option with the "run" script, you can also change the network bindings by editing the server/xxx/conf/bootstrap/bindings.xml file, thus you should be able to elimate port clashes. You can also use the "-b" option to bind to a particular network interface as well (default is 127.0.0.1). There is also a port assignment feature in the server/xxx/conf/bootstrap/bindings.xml file, there is a bean called PortsDefaultBindings that increment the port numbers to use it see below

jboss.service.binding.set option run -c myconfig -Djboss.service.binding.set=ports-01
use a particular interface run -c myconfig -b 192.168.0.1

You can shutdown instances by using the shutdown scripts (or CTRL-C in the window), you must use the JNDI port (default 1099) because it uses the MBeanServerConnection object.

shutting down instances shutdown -s 192.168.0.1:1099 -S

Unwanted Services

There are a number of services that you can disable if you do not require them

Service Delete these files/directories
Mail Service server/xxx/deploy/mail-service.xml
server/xxx/lib/mail*.jar
Scheduler Service server/xxx/deploy/scheduler-service.xml
server/xxx/deploy/schedule-manager-service.xml
server/xxx/lib/scheduler-plugin*.jar
Monitoring Service server/xxx/deploy/monitoring-service.xml
server/xxx/lib/jboss-monitoring.jar
Messaging (JMS) Service server/xxx/deploy/messaging
server/xxx/deploy/jms-ra.rar
server/xxx/lib/jboss-messaging*.jar
Unique ID key generator server/xxx/deploy/uuid-key-generator.sar
server/xxx/lib/autonumber-plugin.jar
HTTP Invoker service server/xxx/deploy/http-invoker.sar
server/all/deploy/httpha-invoker.sar
Home page server/xxx/deploy/ROOT.war
JMX Console server/xxx/deploy/jmx-console.war
Web Console server/xxx/deploy/management
Quartz scheduler service server/xxx/deploy/quartz-ra.rar

You can increase security by editing the server/xxx/conf/login-config.xml, take a look at the security topic for more details.

It might be an idea to change the default database which is the Hypersonic SQL database (HSQLDB) which is a in memory, pure Java database. You can use many of the free databases MySQL, PostgreSQL or a commercial one like Oracle, have a look at the deployment topic on how to set this up. There are a number of services that use the DefaultDS (default data source), so these will have to be updated to point to you new database

Service Configuration File
Login Modules server/xxx/conf/login-conf.xml
Container-Managed Persistence (EJB 2.x) server/xxx/conf/standardjbosscmp-jbdc.xml
Hypersonic Data Source server/xxx/deploy/hsqldb-ds.xml
common/lib/hsqldb*.jar
Timer Service (EJB 2.x) server/xxx/deploy/ejb2-timer-service.xml
Timer Service (EJB 3.x) server/xxx/deploy/ejb3-timer-service.xml
Schedule Manager Service server/xxx/deploy/schedule-manager-service.xml
Messaging Service server/xxx/deploy/messaging/hsqldb-persistence-service.xml
server/xxx/deploy/messaging/messaging-jboss-beans.xml
Universal Description, Discovery and Integration (UDDI) Service server/all/deploy/juddi-service.sar/juddi.war/WEB-INF/jboss-web.xml
server/all/deploy/juddi-service.sar/META-INF/jboss-service.xml
Simple Network Management Protocol (SMNP) Adaptor Service server/all/deploy/snmp-adaptor.sar/attributes.xml
Universally Unique ID (UUID) key generator Service server/xxx/deploy/uuid-key-generator.sar/META-INF/jboss-service.xml

The EJB3 timer service uses the Quartz job scheduler from Open Symphony, the default is to use the Hypersonic database but it can be used with any number of databases. The first thing is to download the Quartz source file that corresponds to the version provided by JBoss. You can get this information from the META-INF/Manifest.mf file located in common/lib/quartz.jar. You need to change two things

ejb3-timer-service.xml You need to change the delegate class to match the one from your database, valid delegates can be found in the src/java/org/quartz/impl/jdbcjobstore directory or the Quartz source.
ejb3-timer-service.xml The SqlProperties attribute contains a number of sql statements that need to be changed to match your database, these can be found in docs/dbTables in the Quartz source.

One note is that the JBoss 5.0.1.GA has now moved the file to the docs/examples/ejb3 directory

JSP Compilation

By default JBoss does not compile a JSP file until the first time it is accessed, after that it checks whether the underlying JSP has changed and recompiles if necessary. In a Production environment you generally release your changed code in a controlled manor, this means that you should turn off lazy JSP compiling feature. This feature is handled by the Java Servlet deployer and the file is located server/xxx/deployers/jbossweb.deployer/web.xml this is well documented within the file so you should have no problems in finding the location you need to change, the options are below

Parameter Description
development if true the frequency at which JSPs are checked for modification can be specified via the modificationTestInterval parameter, default is true
checkInterval If development is false and checkInterval is greater than 0, background compilations are enabled. checkInterval is the time in seconds between checks to see if a JSP needs to be recompiled, default is 0
modificationTestInterval Causes a JSP (and its dependent files) to not be checked for modification during the specified time interval (in seconds) from the last time the JSP was checked for modification. A value of 0 causes the JSP to be checked on every access, used in development mode only, default is 4