Why Subscription Files?

In the past we have had installations that were moved to a different team, with contacts who were unknown to us. When they applied for support it was hard to identify their subscription and this caused needless administrative delays.

The subscription files contain your maven user account name. This helps us identify your subscription and installation details upon support requests.

These subscription files are named as follows:

• atomikos-subscription.properties (the actual subscription information)
• atomikos-subscription.properties.sig (the corresponding signature file - signed by Atomikos)

How to Obtain Your Subscription Files

Existing Installations - Not Yet Expired

You can generate and download your own subscription files with your Atomikos maven user account here. Just login and there should be an automatic zip file download containing the files.

Existing Installations - Expired

Please ask your purchasing department to renew via our customer portal. IMPORTANT: they will need your maven username to indicate which subscription to renew.

New Installations

Please ask your purchasing department to buy a subscription via our customer portal.

How to Install Your Subscription Files

For production use you need to install a valid pair of subscription files.

These subscription files are named as follows:

• atomikos-subscription.properties (the actual subscription information)
• atomikos-subscription.properties.sig (the corresponding signature file - signed by Atomikos)

You can install these in 2 ways:

• Either in your application's classpath, or
• In a folder of your choice, if this folder's path is set as a system property called com.atomikos.icatch.subscription_folder.

Programmatic / In-Memory Subscription Content

Available since ExtremeTransactions 6.0.118. On earlier versions, only the classpath and subscription_folder mechanisms described above are available.

In addition to the file-based mechanisms above, you can supply your subscription content programmatically or from an in-memory source, without ever writing the subscription files to disk. This is useful if your subscription content is resolved from a secrets vault (e.g. Azure Key Vault, HashiCorp Vault, AWS Secrets Manager) or another runtime source, and you want to keep license material out of the filesystem entirely.

Option A -- Register your own provider (SubscriptionContentProvider SPI)

Implement com.atomikos.icatch.config.SubscriptionContentProvider and register your instance before Atomikos starts:

Configuration.setSubscriptionContentProvider(myProvider);

Atomikos calls your provider at startup to obtain the subscription properties and signature as InputStream=s. You are responsible for constructing your provider with whatever client and credentials it needs to reach your vault or source -- Atomikos does not instantiate or configure it for you, the same pattern used for registering a custom =XADataSource.

Option B -- Built-in Base64 provider (no custom class needed)

If you don't need a custom provider class, set these two system properties to the base64-encoded content of your subscription properties and signature files:

• com.atomikos.icatch.subscription_properties_base64
• com.atomikos.icatch.subscription_signature_base64

Populate them with your own secrets tooling (for example, a Kubernetes Secret or a Vault agent) before the JVM starts. This only keeps license material off the filesystem if the base64 value itself is injected at runtime -- don't hardcode it into a script or file that ends up persisted on disk or committed to version control.

Precedence and default behavior

If more than one mechanism is configured, Atomikos resolves subscription content in this order:

1. A registered SubscriptionContentProvider
2. The com.atomikos.icatch.subscription_folder file location
3. The classpath

If you don't configure any of this, nothing changes: with no provider registered and no base64 properties set, Atomikos falls back to the classpath/folder lookup described above, exactly as before.

Note: the "do not rename the files" constraint above applies only to the classpath and subscription_folder mechanisms, where Atomikos looks for the files by their fixed names. It does not apply to the SPI or base64 options -- there, you control how the content reaches Atomikos, so no fixed filenames are involved.