IronJacamar

IronJacamcar 2 / Core

APIs

The API is split into two

  1. Public and supported
  2. Internal and unsupported

The public API only contains interfaces, classes and exceptions which may be used by a resource adapter vendor in order to access IronJacamar specific functionality. The package name for the APIs will have an .api in their name in order to reflect that they are supported. The artifacts for APIs have their Java archive name end in -api.jar.

The internal API only contains interfaces, classes and exceptions which are used by IronJacamar itself. The API may of course be accessed from resource adapters, but it isn't support, and breakage may occur even in patch releases. The package name for the internal APIs will have an impl.api in their name in order to reflect that they are unsupported. The artifacts for internal APIs are included in their implementation specific Java archive.

Recovery

Have the recovery module use the pool as its backing store.

ResourceAdapter repository

The ResourceAdapterRepository keeps track of the ResourceAdapter instances currently activated.

Since a ResourceAdapter instance can be referenced from multiple deployments the tracking needs to be ref-counted.

Much of the code from IronJacamar 1.x can be reused, but usage of String based identifiers should be revisited.

Metadata repository

The job of the MetadataRepository is to keep track of the specification metadata defined by a resource adapter deployment.

The resource adapter may not have a java.io.File associated, so this can't be a mandatory parameter. Make it optional, or do an overloaded method with a classloader as the building block.

TODOs

Most of the IronJacamar 1.x MetadataRepository implementation can go into the new deployment repository.

Deployment repository

The deployment repository keeps track of all deployments, and provide access to the IronJacamar created objects.

The deployment repository is shared by resource adapter and datasource deployments.

DeploymentRepository

Deployment