Overview
Each of the best practices outlined below are intended to be used on an "as needed" basis. Each of the practices put forth here fall into three general sections: Configuration, Development, and Deployment. These sections may be used independently or together as a part of a greater system.
Configuration
Do Not Modify the "all", "default", or "minimal" Configurations
Configurations in JBoss are treated much like server profiles in WebSphere and other application servers. Each directory in server/ corresponds to a server configuration. Each configuration has its own set of applications and settings; this allows a single JBoss installation to run multiple instances of the server.
Administrators should always create a copy of the above configurations rather than modifying the original. This provides a set of known working configurations in the event a new instance needs to be created or debugged
Do Not Deploy Applications to the Server "deploy" Directory
Administrators should instead create a deployment directory elsewhere on the filesystem (see: Configuring the Deployment Scanner in conf/jboss-service.xml). This helps prevent confusion during deployment and reduces the chance of clobbering deployed system services.
Do Not Deploy JDBC Drivers to the Server "deploy" or "lib" Directories
Instead, place the JDBC Drivers in the root of the application deployment directory. This helps prevent confusion during upgrades and reduces the chance of clobbering system libraries.
Update the conf/jboss-log4j.xml
Update the default conf/jboss-log4j.xml logging configuration to disable console logging and increase the logging priority to either INFO or WARN for the file logger. This keeps logging chatter to a minimum which helps reduce the amount of diskspace used by long-running instances.
Secure the Server/Disable Unused Services
See: Securing JBoss
Development
Do Not Rely on Default web-context Behavior
Applications should always define the appropriate web-context for a web application in the jboss-web.xml or application.xml descriptors.
Use the Environment Naming Context (ENC) Where Possible
As the Java EE specifications have matured, the usefulness of the ENC has been somewhat diminished. However, it remains a useful tool for most applications which rely on a number of external resources. It is suggested that a developer make use of the ENC wherever possible as this permits a looser coupling between the application and its environment. Unfortunately, this is not always possible, particularly when defining EJB3 persistence units. Cases in which the ENC is not used should be carefully documented to prevent future confusion.
For more information about JNDI or the ENC, please review the JNDI article.
Choosing an Open Source RDBMS
Choosing the correct RDBMS for your application can be a difficult choice, particularly if your organization does not have an existing infrastructure.
PostgreSQL and MySQL present the two most popular open source options available. It is generally advised that users make use of PostgreSQL, particularly if they are using transactions and/or are within a clustered environment.
Currently, MySQL still has a faster raw-read rate, however this advantage is significantly reduced when performing update operations. Additionally, the speed advantage of MySQL is further diminished if you create InnoDB tables to support transaction semantics and improved concurrent reading and writing (MyISAM tables have a long history of being especially prone to data corruption with concurrent loads).
PostgreSQL has made large gains in performance over the last several releases (particularly in 8.3) which has narrowed the perceived performance gap between itself and MySQL. PostgreSQL also makes use of the MVCC locking model which obviates the need for vast majority of row and table locking semantics used by MySQL. This is a major advantage, particularly in clustered environments (i.e. reduced resource contention between concurrent requesters). PostgreSQL supports a greater subset of the SQL92 and SQL99 standards. PostgreSQL's locking and transaction models are far more mature; InnoDB tables were introduced to MySQL sometime between 2002 and 2003. Stored procedure support is far more mature as well, supporting PL/pgSQL (similar to Oracle's PL/SQL) and procedures written in a number of other host languages (i.e. C/C++, Java, Python).
An excellent article on this topic is available here:
http://www.enterprisedb.com/learning/articles/why_postgres.do
Deployment
Application Naming
Each application should have a unique lowercase name (i.e. Application Name) that can be used to act as an identifier for various system services. For example, The Customer Management application could use the name customer-mgmt.
Filesystem Layout
Applications deployed from the filesystem should have a top level deployment directory named after the Application Name which contains the application and associated bindings. For example, if the primary deployment directory is /deploy, the Customer Management application (i.e. customer-mgmt.ear) and its bindings (i.e. MYAPP-ds.xml) should be placed in /deploy/customer-mgmt.
JMX Resource Naming
Any application requiring the use of MBeans should create a unique root JMX name after the Application Name. For example, if the JNDI Binding Service is used for the Customer Management application, the mbean name should be customer-mgmt:service=JNDIBindingServiceMgr.
JNDI Resource Naming
Most applications are run on shared server instances. As such, it is important to ensure that JNDI conflicts do not occur at deployment. The following best practices are helpful, even for applications running on dedicated instances.
Each application should have a root JNDI context in the global namespace named after the Application Name (i.e. Application Context). For example, the Customer Management application would have a root context named /customer-mgmt.
All resources should still follow traditional naming conventions under the Application Context. For example, a DataSource named MYAPP for the Customer Management application would be placed under /customer-mgmt/jdbc/MYAPP.
ENC references should not reference the Application Context. For example, a DataSource with a reference name of jdbc/MYAPP would be looked up using the ENC name java:comp/env/jdbc/MYAPP. Making use of JNDI names outside of the ENC makes it difficult to correctly port applications to different environments as application servers vendors often have differing naming conventions.
By default, DataSources jndi-names are automatically placed in the java: namespace. To disable this behavior (i.e. to use the global namespace), the DataSource should be defined with use-java-context set to false. The JBoss EJB3 container places all references in the global namespace; placing DataSources and other managed objects in the same location eases administration and configuration.