Red Hat

In Relation To Jesper Pedersen

In Relation To Jesper Pedersen

IronJacamar 1.1.0.Beta5 is out !

Posted by    |       |    Tagged as

I'm happy to announce the release of IronJacamar 1.1.0.Beta5.

Full release notes are here.

Security inflow

We have finished up our security inflow model for our WorkManager, which allows you to configure mapping of users and groups in the Enterprise Information System domain to the domain used in the application server.

If you have additional use-cases that isn't covered by the existing configuration schemas let us know.

Improvements, improvements, and more improvements

This release really aims to finish up the work left on IronJacamar 1.1, so you will see a lot of small / bigger improvements in most of our components, like

And a ton of bug fixes. So, all in all, a release that should make you say Yummi !.

The Road Ahead

We aim to submit this release for inclusion in WildFly, and we further hope that this will be the last Beta release in the 1.1 series. So now is the time people if you are looking for something in the Java EE Connector Architecture space !

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

IronJacamar 1.1.0.Beta4 is out

Posted by    |       |    Tagged as

I'm happy to announce the release of IronJacamar 1.1.0.Beta4 - the first release of IronJacamar that targets the upcoming Java EE Connector Architecture 1.7 specification scheduled for inclusion in the Java EE 7 platform specification.

Full release notes are here.

Pool on steroids

We spent a lot time in this release going over our pool implementation, which of course controls all the physical connections to the Enterprise Information Systems such as databases.

Capacity policies

First off we added support for capacity policies. So what is a capacity policy, and why is it important. Capacity policies are divided into two categories: incrementers and decrementers.

An incrementer capacity policy specifies the properties when a new physical connection should be added to the pool, such as

  • MaxPoolSize -- increase to max-pool-size
  • Size -- increase by a certain size
  • Watermark -- increase until a certain size is reached

The incrementer policy will allow you to control how many or a specific size of the pool that is created when a connection isn't available for immediate check out. The default policy will remain the Size policy with a value of 1.

A decrementer capacity policy specifies the properties when the pool is scheduled for idle timeout cleanup, such as

  • MinPoolSize -- remove connections until min-pool-size is reached
  • Size -- remove a certain number of connections
  • TimedOut -- remove all connections that are registered with the timed out flag
  • Watermark -- remove connections until a certain size is reached

The decrementer policy will allow you to optimize the resources used in a pool each time idle timeout is scheduled. The default policy will remain the TimedOut policy.

You can read more about the capacity policies here.

Flush strategies

Next we looked at our flush strategies, which specifies which connections that are removed in case of an error on a connection. This led to

  • FailingConnectionOnly (default)
  • InvalidIdleConnections (new - will remove invalid idle connections)
  • IdleConnections
  • Gracefully (new - will remove all idle connections, and mark checked out connections for destruction upon return)
  • EntirePool

and their related strategy which works on all sub-pools across credentials. This allow much finer control of the pool in error situations.


We added some new metrics to our statistics too

  • AverageGetTime
  • MaxGetTime
  • TotalGetTime
  • InUse
  • BlockingFailureCount
  • WaitCount

to give a more detailed view of the run-time behaviour of pool.

Initial size

Last we added support for specifying the initial size of the pool upon start up.

Hopefully you find all these changes just as exciting as us !


The DistributedWorkManager implementation also got an update, and both the Socket and JGroups transports are now considered ready for general testing, so give them a spin.

In order to help creating a cluster of IronJacmar instances we added some Apache Ant tasks, and Apache Maven mojos to control IronJacamar instances. Our test suite features test cases for both transports, so you can get an idea of how a cluster is created by looking there.

Java EE Connector Architecture 1.7

As stated above, this release targets the upcoming Java EE Connector Architecture 1.7 specification which will be included in the Java Enterprise Edition 7 platform specification.

The specification adds some new feature, but remains backwards compatible with the previous releases of the specification. I'll discuss these new features once the specification have received the final approval.

So hopefully soon you will see this release featured in the upcoming JBoss Application Server 8.0 release.

Other changes

There were other changes in this release

  • Initial support for converting a weblogic-ra.xml resource into an IronJacamar one
  • Numerous component updates in order to align against our EE 7 implementation
  • Bucket of bug fixes

The Road Ahead

A lot of changes (phew!) over the last 3 months to bring IronJacamar into a new league. But we are of course not stopping there - we still got more changes planned before we go into feature freeze for JCA 1.7 certification. So if you have a good idea now is the time to speak up in our forum !

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

IronJacamar 1.1.0.Beta3 is out

Posted by    |       |    Tagged as

I'm happy to announce the 3rd beta release of the IronJacamar 1.1 series.

The full release notes are here.


Our DistributedWorkManager implementation got a huge update in this release.

The distributed work manager is now unique per resource adapter activation - the same goes for the BootstrapContext. This means that these components acts like singletons, if multiple resource adapter activations uses the same configuration. This allows us to uniquely identify each instance within the JVM, and more importantly across the entire network, which allows us to optimize traffic and state between all the nodes in the cluster.

We now have a distributed statistics implementation across the network which will allow you see the status of all your Work instances in addition to the local statistics instance.

Since the WorkManager is now unique within the JVM we had to eliminate our InVM transport implementation. However, we have added Apache Ant and Apache Maven support for our standalone distribution in order to quickly start, stop, deploy, undeploy and ping local or remote instances of the IronJacamar container to ease testing and control of JCA clustering features.

We will continue to work on the implementation, and hope that we can consider the implementation stable in our next beta release. The JGroups transport have some caveats in this release, but give the Socket one a spin.


Our Arquillian support got an update as well. We now support the @ArquillianResource annotation in order to allow access to internally used resources, like the embedded instance, as well as the JNDI context.

However, since we have an increased focus on having IronJacamar running on a local machine as well as in a cluster we decided to split the Arquillian support in its own component to allow for multiple implementations (embedded and remote) in the future. This meant that we had to change the package name from 'org.jboss.jca.embedded.arquillian' to 'org.jboss.jca.arquillian.embedded'. Now, we can just wait for the mob with pitchforks...

Eclipse plugin and tooling

Our Eclipse plugin got a major update in this release, as did our general tooling for code generation.

The Eclipse plugin will now allow you to validate and deploy your resource adapters and their activation configuration to a local or remote IronJacamar instance.

Our code generator now allows you to integrate our EIS test server instance in your development environment easily, so you don't have to depend on having a full EIS installation.

You will be able to see it all in action this week at JUDCon/Beijing !

Other stuff

The usual bug fixes, and improvements in other area of the release, so all in all a good reason to upgrade your development environments.

Remember to switch to a JDK7 profile !

The road ahead

We still have a way to go for our 1.1 goals, but we are getting closer with each step. We are still aiming for certification once EE 7 is released.

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

IronJacamar 1.1.0.Beta2 is out

Posted by    |       |    Tagged as

I'm happy to announce the 2nd beta release of the IronJacamar 1.1 series.

The full release notes are here.

Developer productivity

In this release we took a hard look at how resource adapter development is done, and what it would take to be more productive. The previous releases of IronJacamar have featured an embedded environment, and various tools to help you get started. But more was needed in our view.

First we got rid of the requirement to have an on-disk representation of the IronJacamar deployment descriptors. So now you are able to deploy a ShrinkWrap/Descriptor instead for all these XSDs.

Next was the ability to test your resource adapter in error scenarios such that you are sure that it'll behave correctly. For this we integrated the Byteman tool in the embedded environment.

Then, the biggest problem in resource adapter development: Access to the Enterprise Information System (EIS). An EIS can be large installation, and in many cases it isn't really suited to run as part of a developer test suite run, since they don't really integrate well with embedded unit testing. So we have included an EIS test server in our distribution where you can implement a Handler interface that mocks the communication protocol of the EIS in order to make your smoke tests pass without an actual EIS installation. The EIS test server can run in Apache Ant, Apache Maven and standalone environments, so you should be covered in most cases. Otherwise let us know. Our code generator of course knows how to handle the integration, so you can check it out that way. And I'm not saying that using the EIS test server is enough for your resource adapter to go into a real test or production environment; it is a help for resource adapter developers, not a golden bullet.

Finally we upgraded the libraries used for our embedded platform in order to get the latest fixes.

You can find more information here:

And our Eclipse plugin have been verified on Eclipse 4.2 (Juno) to top it off :)

DistributedWorkManager on steroids

The DistributedWorkManager saw a big update in this release.

Our policy module was updated with a WaterMark implementation, which will look at how many free threads are available to the local WorkManager. The default setup is a value of 0, which will start to distribute Work instances once there are no free threads locally.

Our selector module got a MaxFreeThreads implementation, which will select the DistributedWorkManager in the cluster with the most free threads available for execution.

The real kicker was the addition of a JGroups based transport, which will allow you to configure the cluster parameters in much more detail taking IronJacamar into NFL. No more college football here.

Now that we have all the core modules, we will focus on implementation details that will tackle more advanced scenarios of distribution and thread management.

And the core WorkManager implementation also saw numerous fixes to align it more against the specification text.

Other improvements

There were other improvements in this release:

  • Updates to our validator tool
  • Major updates to our resource adapter information tool
  • Updates to the JDBC resource adapter, especially in the reauth area
  • Added support for deploying to a remote IronJacamar installation

Good stuff.

The Road Ahead

In short - it is full speed ahead !! We now got THE best platform for resource adapter development - prove us wrong ! This will enable us to get our new features tested and verify your reports about potential bugs at a quicker speed.

With EE7 getting closer we will focus in a higher degree on getting IronJacamar 1.1 ready for certification, and making sure that all of the specification is covered.

IronJacamar 1.1.0.Beta2 will be our last release on Java SE 6 - the time has come to move to Java SE 7.

For Those About to Rock, We Salute You !

[WebSite [Download] [Documentation] [JIRA] [Forum]

IronJacamar 1.1.0.Beta1 is out

Posted by    |       |    Tagged as

I'm very happy to announce the first beta of the IronJacamar 1.1 series ! This is a major milestone for us, since this release adds support for the optional features of the Java EE Connector Architecture 1.6 specification.

Full release notes are here.

Lazy connection manager

This release finishes our work on our lazy connection manager implementation. We covered the association part in an earlier blog which leaves the enlistment part.

Lazy enlistment allows the resource adapter to control when the ManagedConnection is enlisted in the transaction associated with the invocation. This has the benefit of not having the enlistment overhead if the connection never needs to be enlisted.

So for resource adapters that supports read-only scenarios you will see a nice performance improvement.

Distributed work manager

This release features our initial distributed work manager, which allows instances to be reschedule for execution in another work manager instance to which it was submitted.

The distributed work manager is basically a standard work manager with three additional components

  • Policy
  • Selector
  • Transport

The Policy decides when a DistributableWork instance should be executed in another work manager. We currently support

  • Never -- never distribute to another work manager
  • Always -- always distribute to another work manager

More policies are on their way.

The Selector decides which work manager that should receive the DistributableWork instance. We currently support

  • FirstAvailable -- pick the first work manager in the list that is available
  • PingTime -- pick the work manager which has the lowest ping time

Future releases will include more selectors.

The Transport handles the actual transport of the DistributableWork instance. We have included support for the following transports

  • InVM -- communication between work managers in the same JVM
  • Socket -- communication between work managers using standard Java sockets

in this release. We will include support for additional transports in future releases.

We have added a org.jboss.jca.core.api.workmanager.DistributableContext class which will allow you to define overrides to control the execution.

If you thought to yourself Did IronJacamar just get support for clustering ? - the answer would be yes !

Eclipse plugin

We now have a plugin for the Eclipse development environment, which provides an Eclipse integration for our code generator such that you don't have to use the command line to generate the project skeleton for your resource adapter.

We will of course integrate our other tools, such as the validator, into the plugin in future releases.

The Road Ahead

This is the first beta release of IronJacamar 1.1 which means we are getting closer a stable release, but there is still a lot of work that needs to be done. But that is what Beta's are for :) And don't forget your own ideas for the project, keep the feedback coming !

Looking forward to meeting you all at JUDCon !

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

IronJacamar 1.1.0.Alpha7 is out

Posted by    |       |    Tagged as

I'm happy to announce the 7th alpha release of our IronJacamar 1.1 series.

Full release notes are here.


This release adds support for the datasources-1_1.xsd schema, which adds the


element, which tells the pool implementation to switch to an implementation that accounts for multiple users accessing the datasource instance through the datasource.getConnection(user, password) method.

We have updated the datasources subsystem in JBoss Application Server 7 to support this new schema too.

Arquillian and friends

This release also features Arquillian 1.0.0.Final and its friends making the foundation for our embedded testing environment.

A congrats to our friends in the Arquillian community for their first stable release !

Other changes

Worth to mention is also

  • Updates to our code generator
  • New security inflow module
  • Bug fixes

Be sure to check that out too.

The Road Ahead

We still have a number of outstanding features before we can release, so the race is on :) Of course we will keep an eye out for issues popping up with JBoss Application Server 7, and our upcoming JBoss Enterprise Application Platform 6.0 release.

And, if you didn't sign up for JUDCon/Boston yet do it now. I'll open the show with my The Bird and the Cheetah - A Tale from the Depths of JBoss Application Server talk where we will take a deep dive into why Java EE Connector Architecture is so important for an application server, and how to configure your deployments.

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

IronJacamar 1.1.0.Alpha6 is out

Posted by    |       |    Tagged as

I'm happy to announce the 6th alpha release of our IronJacamar 1.1 series.

Full release notes are here.

Lazy connection manager

This release marks one of the first new major features of the IronJacamar 1.1 series over the stable release used in JBoss Application Server 7.1 namely the first commit of our lazy connection manager.

So what is a lazy connection manager and why should you care ?

The lazy connection manager is an optional part of the Java EE Connector Architecture 1.6 specification and is divided into two parts

Our first commit is in the associatable part, which will allow the JCA container to reassign physical connections to other logical connection handles.

Eh, what ? You may say... Ok, lets say you have an application which uses connections to an Enterprise Information System (EIS):

Connection c1 = myEIS.getConnection();

// Do work with c1

Connection c2 = myEIS.getConnection();

// Do work with c2


But what happens if there is only one physical connection to the EIS available ? The c2 will get a timeout on the creation call, since all connections are controlled by the JCA container.

This is where the associatable part comes into the picture; IronJacamar will detect that the application is asking for another connection, but there aren't any available in the pool. IronJacamar will then ask the EIS resource adapter to dissociate the physical connection for c1 and attach it to c2. Whenever either c1 or c2 is used it is up to the resource adapter to make sure that the physical connection handle is valid against the logical one.

This basically allows you to multiplex connection handles on fewer physical connections; say 1000 to 100, and thereby saving system resources in the EIS layer.

Just to give you an idea of how a resource adapter could look we have added a HelloWorld/Lazy example to our documentation.

And you can disable the functionality - if your resource adapter supports it - by setting the sharable attribute to false.

A note to the hard-core group of the JCA community; we have extended the specification API with the following methods:

    * Associate a managed connection to a logical connection
    * @param connection The connection
    * @param mcf The managed connection factory
    * @param cri The connection request information
    * @return The managed connection
    * @exception ResourceException Thrown if an error occurs
   public ManagedConnection associateManagedConnection(Object connection, ManagedConnectionFactory mcf,
                                                       ConnectionRequestInfo cri)
      throws ResourceException;

    * Dissociate a managed connection from a logical connection. The return value
    * of this method will indicate if the managed connection has more connections
    * attached (false), or if it was return to the pool (true).
    * If the managed connection is return to the pool its <code>cleanup</code> method
    * will be called
    * @param connection The connection
    * @param mc The managed connection
    * @param mcf The managed connection factory
    * @return True if the managed connection was freed; otherwise false
    * @exception ResourceException Thrown if an error occurs
   public boolean dissociateManagedConnection(Object connection, ManagedConnection mc, ManagedConnectionFactory mcf)
      throws ResourceException;

The first method will help you, if you doesn't have an easy link between the connection and the managed connection; the associateConnection callback will still happen - keep that in mind.

The second method will allow you to dissociate the managed connection when you know you aren't going to use it for a while. Thereby making it easier for the JCA container to hand it out to other callers. This use-case isn't part of the existing JCA specification. Yummi stuff.

This is only the first step, but we are on our way now :)

Other changes

The other changes in this release are mostly around fixing bugs found during our testing with JBoss Application Server and our upcoming JBoss Enterprise Application Platform release.

There is a nice update to our code generator though, which should give you a better starting point for your development.

The Road Ahead

Testing continues, and we have more cool stuff in the pipeline, so be sure to check back, or give us a shout in our forums.

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

Tattletale 1.2.0.Beta2 is out

Posted by    |       |    Tagged as

I have released Tattletale 1.2.0.Beta2 to the community for testing.

Full release notes are here.

Bug fixes

The release mainly contains bug fixes for the issues found by the community. Over 1200 downloads of Beta1 is quite impressive, so keep the feedback coming !

This release should work better on that other OS too...

JBoss Application Server 7

The JBoss Application Server 7 plugin has been updated to the JBoss Application Server 7.1.0.Final release, so that should get your applications up and running on that release faster :)


There are still ideas that we are working on, so if you are interested in helping out with Tattletale development feel free to drop by our forums and fork the code from GitHub.

For Those About to Rock, We Salute you !

[WebSite] [Download] [Documentation] [Forum] [JIRA]

IronJacamar 1.1.0.Alpha5 is out

Posted by    |       |    Tagged as

I'm happy to announce the 5th developer snapshot of the IronJacamar 1.1 container, which implements the Java EE Connector Architecture 1.6 specification.

Full release notes are here.

Bugs, what bugs ?

This release mainly contains bug fixes that we have found during our testing with IronJacamar inside JBoss Application Server 7.1.

The fixes has of course been included in the upcoming JBoss Application Server 7.1.0.Final release.

Spring cleaning

We have begone our spring cleaning of the project to provide the foundation of the upcoming features of the 1.1 series, which we should start to see really soon now.

If you look at our code repository you should at least get one hint ;)

But more on that later...

JBoss Application Server 7.1.0.CR1b

The JBoss Application Server 7.1.0.CR1b release is out featuring IronJacamar 1.0.7.Final, so give that release a good run and report any issues that you may find. Be sure to check the forums for possible answers first though.

We have fixed additional issues post that release, so feel free to try a nightly snapshot too.

The Road Ahead

We are pushing to get all the remaining JCA and datasources issues fixed before JBoss AS goes Final, so your help is highly valued one way or the other.

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

IronJacamar 1.1.0.Alpha4 is out

Posted by    |       |    Tagged as

I'm happy to announce the 4th developer snapshot of the IronJacamar 1.1 series.

Full release notes are here.

Resource adapter information tool

This release adds a resource adapter information tool, that can provide the important information about the resource adapter and a sample deployment descriptor.

The information about the resource adapter is generated using the following command:

./ myeis.rar

where the report will be located in myeis-report.txt. The tool can take an optional -classpath parameter such that additional external dependencies can be resolved against the resource adapter.

The report will contain information about

  • The name of the resource adapter
  • The Java EE Connector Architecture specification version
  • The type of the resource adapter
  • If the resource adapter supports reauthentication
  • If the resource adapter is compliant (see the validator tool)
  • If the resource adapter contains native libraries
  • Overview of the resource adapter class
  • Overview of the managed connection factory classes
  • Overview of the admin object classes
  • Overview of the activation specification classes
  • A sample deployment descriptor

The tool ( is located in the doc/as/ directory of the distribution. Try it out and send us your thoughts :)

JBoss Application Server 7.1.0.Beta1

The JBoss Application Server 7.1.0.Beta1 release is out featuring IronJacamar 1.0.5.Final, so give that release a good run and report any issues that you may find. Be sure to check the forums for possible answers first though.

As seen by the 1.1.0.Alpha4 release notes we have found some more bugs - the fixes should make their way into JBoss AS7 soon.

The Road Ahead

We will keep pushing to make JBoss Application Server 7.1.0.CR1 the best application server out there to deploy resource, adapters on, so we value any feedback that you will send.

For Those About to Rock, We Salute You !

[WebSite] [Download] [Documentation] [JIRA] [Forum]

back to top