www.ironjacamar.orgCommunity Documentation

Chapter 4. Configuration

Table of Contents

4.1. IronJacamar server
4.1.1. Using the leak detector pool
4.1.2. Allow obtaining connections during MARKED_FOR_ROLLBACK
4.1.3. Disable enlistment trace
4.1.4. Disable delistResource calls
4.1.5. Disable setRollbackOnly calls
4.2. Logging service
4.3. Transaction service
4.4. JCA
4.4.1. Deployer
4.4.2. Work manager
4.4.3. Security
4.5. Datasources
4.6. Web server

The configuration for the IronJacamar container is mainly located under the config/ directory.

The IronJacamar server can be configured by including an ironjacamar.properties file next to the ironjacamar-sjc.jar in the bin/ directory.

This file will allow to override the core options given to the kernel environment, if multiple instances of the IronJacamar container are going to run on the same machine, and network interface.

The options available

An example of an ironjacamar.properties file:


The IronJacamar container uses JBoss Logging framework as the implementation.

The configuration is done in the



Consult the JBoss Logging documentation on how the service can be configured.

The IronJacamar container uses Narayana its transaction implementation.

The configuration is done in the



Consult the Narayana documentation on how the service can be configured.

The IronJacamar deployer is configured in the



The configuration of the resource adapter deployer chain is handled by a org.jboss.jca.deployers.fungal.RAConfiguration bean.

<bean name="RAConfiguration"
  <property name="ArchiveValidation">true</property>
  <property name="ArchiveValidationFailOnWarn">false</property>
  <property name="ArchiveValidationFailOnError">true</property>
  <property name="BeanValidation">true</property>
  <property name="PrintStream">
    <inject bean="JBossStdioContext" property="Out"/>
  <property name="DefaultBootstrapContext">
    <inject bean="DefaultBootstrapContext"/>
  <property name="JndiStrategy"><inject bean="JndiStrategy"/></property>
  <property name="TransactionManager">
    <inject bean="RealTransactionManager"/>
  <property name="MetadataRepository"><inject bean="MDR"/></property>

Table 4.2. Resource adapter deployer configuration

ArchiveValidationboolean Toggle archive validation for the deployment units.

Default: true

ArchiveValidation​FailOnWarnboolean Should an archive validation warning report fail the deployment.

Default: false

ArchiveValidation​FailOnErrorboolean Should an archive validation error report fail the deployment.

Default: true

BeanValidationboolean Toggle bean validation (JSR-303) for the deployment units.

Default: true

DefaultBootstrap​Contextorg.jboss.jca.​core.api.bootstrap.​CloneableBootstrap​Context Specifies the default bootstrap context for resource adapters
BootstrapContextsMap<String, ​org.jboss.jca.​core.api.bootstrap.​CloneableBootstrap​Context> Bootstrap context map (unique name to a cloneable bootstrap context) which allows developers to bind (through ironjacamar.xml) their resource adapter to a specific bootstrap context instance.
PrintStreamjava.io.PrintStream Specifies which print stream that should be used to handle the LogWriters
MetadataRepositoryorg.jboss.jca.​core.spi.mdr.​MetadataRepository The metadata repository
ResourceAdapterRepositoryorg.jboss.jca.​core.spi.rar.​ResourceAdapterRepository The resource adapter repository
ScopeDeploymentboolean Should each deployment be scoped (isolated) from the container. This feature allows deployment of libraries of a different version than used in the container environment.

Default: false

JndiStrategyorg.jboss.jca.​core.spi.naming.​JndiStrategy Specifies the JNDI strategy policy for binding the connection factories into the naming environment

The JNDI strategies are located in the org.jboss.jca.core.naming package

  • NoopJndiStrategy: A no operation JNDI strategy which doesn't bind/unbind any objects
  • SimpleJndiStrategy: A simple JNDI strategy which can bind/unbind a single connection factory
  • ExplicitJndiStrategy: A JNDI strategy which can requires explicit JNDI names to bind/unbind a connection factory

IronJacamar features a standard work manager on its default setup using one thread pool for short running jobs, and one thread pool for long running jobs identified by the HintsContext.LONGRUNNING_HINT with a value of true.

The configuration of the work manager and the necessary components can be viewed in the jca.xml file.

A distributed work manager is a work manager instance, which is able to reschedule work execution on another work manager instance on the network.

The distributed work manager has three additional components

to control the distribution process.

Supported policies

Supported selectors

Supported transports

Below is an example of a socket based configuration where two instances localhost:1299 and localhost:1300 communicates, taken from the IronJacamar test suite.


  <!-- DistributedWorkManagerThreadGroupSocket -->
  <bean name="DistributedWorkManagerThreadGroupSocket"

  <!-- DistributedWorkManagerThreadFactorySocket -->
  <bean name="DistributedWorkManagerThreadFactorySocket"
      <parameter><inject bean="DistributedWorkManagerThreadGroupSocket"/></parameter>

  <!-- DistributedWorkManagerShortRunningThreadPoolSocket -->
  <bean name="DistributedWorkManagerShortRunningThreadPoolSocket"
      <!-- Core threads -->
      <!-- Max threads -->
      <!-- 60 seconds keepalive -->
      <parameter><inject bean="KeepAliveTimeUnit"/></parameter>
      <!-- Queue size -->
      <!-- Thread factory -->
      <parameter><inject bean="DistributedWorkManagerThreadFactorySocket"/></parameter>
      <!-- Blocking -->
      <!-- Handoff executor -->
      <parameter><inject bean="RejectingExecutor"/></parameter>
    <destroy method="shutdown"/>

  <!-- DistributedWorkManagerPolicySocket -->
  <bean name="DistributedWorkManagerPolicySocket"

  <!-- DistributedWorkManagerSelectorSocket -->
  <bean name="DistributedWorkManagerSelectorSocket"

  <!-- DistributedWorkManagerTransportSocket -->
  <bean name="DistributedWorkManagerTransportSocket"
    <!-- The id -->
    <property name="Id">1</property>

    <!-- The executor -->
    <property name="ExecutorService">
      <inject bean="Kernel" property="ExecutorService"/>
    <!-- The host -->
    <property name="Host"></property>
    <!-- The port -->
    <property name="Port">1299</property>
    <!-- The peers -->
    <property name="Peers">
      <set class="java.util.HashSet" 

    <start method="startup"/>
    <stop method="shutdown"/>

  <!-- PicketBox -->
  <bean name="PicketBoxSocket"

  <!-- DistributedWorkManagerSocket -->
  <bean name="DistributedWorkManagerSocket"

    <!-- The name -->
    <property name="Name">DWM-Socket</property>

    <!-- The short running thread pool -->
    <property name="ShortRunningThreadPool">
       <inject bean="DistributedWorkManagerShortRunningThreadPoolSocket"/>

    <!-- The XA terminator -->
    <property name="XATerminator">
       <inject bean="TransactionIntegration" property="XATerminator"/>

    <!-- The callback security module -->
    <property name="CallbackSecurity">
       <inject bean="Callback"/>

    <!-- The security integration module -->
    <property name="SecurityIntegration">
       <inject bean="PicketBoxSocket"/>

    <!-- The policy -->
    <property name="Policy">
       <inject bean="DistributedWorkManagerPolicySocket"/>

    <!-- The selector -->
    <property name="Selector">
       <inject bean="DistributedWorkManagerSelectorSocket"/>

    <!-- The transport -->
    <property name="Transport">
       <inject bean="DistributedWorkManagerTransportSocket"/>

    <!-- <destroy method="shutdown"/> -->

  <!-- DistributedBootstrapContextSocket -->
  <bean name="DistributedBootstrapContextSocket"
    <property name="Name">DWMBC-Socket</property>
    <property name="TransactionSynchronizationRegistry">
       <inject bean="TransactionSynchronizationRegistry"/>
    <property name="WorkManagerName">
       <inject bean="DistributedWorkManagerSocket" property="Name"/>
    <property name="XATerminator">
       <inject bean="TransactionIntegration" property="XATerminator"/>



The IronJacamar project can deploy datasources using the datasources-1_0.xsd, datasources-1_1.xsd or datasources-1_2.xsd schemas.

The configuration is done in the



The datasource deployer can be removed from the environment by removing the ds.xml file in


as well as the reference in config/bootstrap/bootstrap.xml to the file.

Furthermore all jdbc-*.rar files in the system/ directory should be removed too.

The IronJacamar project features a web server which is used to serve web archive deployments. More information about Jetty can be found at the homepage.

The configuration is done in the



<bean name="WebServer" class="org.jboss.jca.web.WebServer">
  <property name="Host">${iron.jacamar.bindaddress:localhost}</property>
  <property name="Port">8080</property>
  <property name="ExecutorService"><inject bean="Kernel" property="ExecutorService"/></property>


The web server can be removed from the environment by removing the web.xml file in


Furthermore all .war files in the same directory should be removed too.

All the Jetty libraries can be removed by deleting the