Default Jboss configuration set is located in the conf directory. JBoss allows possibility of more than one configuration set which are easily created and maintained. All you have to do is to copy all the files from the default configuration and place under a new directory in conf. For example, "myjboss" configuration (directory) would contain the same files as default configuration but with possibly altered certain setting. When invoking JBoss through platform-dependent scripts just pass configuration name as a paramater. For example run.bat myjboss
There are a number of configuration files for JBoss. The contents of each are give here:
This is a standard Java Properties format file that is loaded into the System properties on startup of the JBoss server. System properties that are not required to be available prior to invocation of the JBoss server main method can be specified here.
Configuration file jboss.conf typically contains only those core service MBeans that are necessary to achieve the initial "bootstrap" of JBoss . These services include the classpath extension inclusion mechanism shown in Figure 2.2. , logging ,configuration service, service control, etc.
<MLET CODE="org.jboss.util.ClassPathExtension" ARCHIVE="jboss.jar" CODEBASE="../../lib/ext/"> <ARG TYPE="java.lang.String" VALUE="../../log/"> </MLET>
This file is loaded by an instance of the javax.management.loading.MLet class and uses standard MLET syntax for JMX MBeans (refer to JMX specification for more details). Any standard JMX MBean could be placed in the jboss.conf file as long as it does not depend on JBoss service MBeans like naming. MBeans that do depend on JBoss service MBeans need to be configured in the jboss.jcml file so that startup dependencies can be controlled.
Usually you would never have to change this file.
This file lists all JMX MBeans (services) that are going to be included in running instance of JBoss. Notice that contrary to the MLET syntax, this file contains well-formed XML.
The need for deviation from MLET syntax is justified since MLET doesn't allow named parameters, but rather only TYPE-VALUE pairs. Having only TYPE-VALUE pairs easily leads to mismatching MBean parameters problems.
jboss.jcml syntax allows named parameters to be used in MBean instantiation directives and is as such mush easier to use. For example, Figure 2.3. shows MBean element for creating and including MailService in JBoss.
<mbean code="org.jboss.mail.MailService" name="DefaultDomain:service=Mail"> <attribute name="JNDIName">Mail</attribute> <attribute name="ConfigurationFile">mail.properties</attribute> <attribute name="User">user_id</attribute> <attribute name="Password">password</attribute> </mbean>
In a nutshell:
The jboss.jcml file is loaded by the org.jboss.configuration.ConfigurationService MBean. This service acts much like the standard JMX MLet class in that it loads and configures MBeans. The dependencies between MBeans are managed by the org.jboss.util.ServiceControl MBean. The ServiceControl MBean listens for REGISTRATION_NOTIFICATION and UNREGISTRATION_NOTIFICATION JMX events to determine which MBeans are available. The order of registration determines the order of initialization and startup. The ServiceControl expects that MBeans which require depdendency management to conform to the org.jboss.util.Service interface. This interface allows for the ordered initialization, starting, stopping and destorying of MBeans. The ordering is based on the order in which MBeans are specified in the jboss.jcml file. See the section called “How to Integrate Custom Services via MBeans” for the details of creating an MBean with depedencies on other MBeans.
For the reason of simplicity and ease of configuration JBoss's DependancyManager was deprecated in 2.1 release, so this file is no longer used.
Now all MBeans listed in jboss.jcml have "vertical" dependency on each other. For example, JNDI provider is required for DataSource wrappers since DataSource wrapper has to store reference to itself in JNDI, thus JNDI provider MBean has to be listed before DataSource wrapper. See the section called “How to Integrate Custom Services via MBeans” for the details of the depedency mechanism.
JBoss has a very powerful feature of being able to record runtime snapshot of all of it's running MBeans including their attributes and then later reproduce that snapshot in another JBoss instance.
When such snapshot is taken it is recorded in xml format in jboss-auto.jcml file.
Consider the following scenario:
Administrator takes a running JBoss instance, adds a few MBeans, modifies attributes of other few MBeans , saves configuration and finally gracefully shuts JBoss.
Next time when JBoss is started all dynamically added Mbeans from previous run are recreated and their attributes set. Jboss also resets any other modified attributes no matter if MBean was added dynamically(runtime) or statically (through jboss.jcml).
Dependency between jboss.jcml and jboss-auto.jcml
If you are using both jboss.jcml and jboss-auto.jcml capabilities you have to note the following. If there is a need to remove any of the MBeans listed in jboss.jcml you also have to remove it from jboss-auto.jcml (if such is listed in jboss-auto.jcml ) to achieve the desired effect.
You also have an option not to use the advanced feature of jboss runtime snapshots, in which case you can safely delete jboss-auto.jcml file without affecting JBoss. In this case you won't have an option of recording any changes to MBeans made in runtime.
JBoss , according to EJB spec provides mail resource access utilizing standard JavaMail APIs. This file specifies provider properties, i.e where to find smtp server, pop server, as well as other mail related configuration.
Note that you are allowed to have multiple set of configurations by having multiple mail.properties files. All you have to do is to specify additional MailService mbeans with different "ConfigurationFile" attributes in your jboss.jcml file. See the section called “Using JavaMail in JBoss” for additional details.
These two files are JNDI related. The first one contains properties of the JBoss's JNDI provider implementation - JNP while jndi.properties specifies properties for JNDI clients.
JNDI clients can specify properties listed in jndi.properties and drop jndi.properties file anywhere in their classpath. This way you don't have to specify these properties in the actual code which leads to greater code portability. Note that you have to change java.naming.provider.url=localhost property-value pair if you are using clients that reside on the machine other than the JBoss server itself.
Represents a default configuration file for JBossCMP engine. It contains jndi name of a default DataSource , per database Object -jdbc- sql mappings , default CMP entity beans settings etc. See Chapter 5., Customizing JAWS for additional details.
This file is a JAAS login module configuraiton file as supported by the default javax.security.auth.login.Configuration implementation. It contains sample server side authentication configurations that are applicable when using JAAS based security. See Chapter 9., JBossSX Security Extension Framework for addition details on the JBoss security framework.
The default Java2 security policy for the JBoss server. Currently, this is set to allow all permissions and is unused as the JBoss server does not run with a security manager by default. See Chapter 9., JBossSX Security Extension Framework for a description of the JBoss security framework.
This file provides the default container configurations. Use of this file is an advanced topic covered by Chapter 6., Advanced container configuration : use of jboss.xml