Here are the configurations that currently support DataSource or Resource configuration:
Notes:
jtm
service.DataSources are added through pipe-delimited configuration properties that starts with cargo.datasource.datasource
. Example:
cargo.datasource.datasource1=cargo.datasource.url=jdbc:mydriver:userdb\|cargo.datasource.driver=org.database.Driver\|... cargo.datasource.datasource2=cargo.datasource.url=jdbc:mydriver:referencedb\|cargo.datasource.driver=org.database.Driver\|... |
Here are the properties that are valid for this:
c.d
means cargo.datasource
CargoException
.Property | Purpose | Valid Values | DataSource | Transactional DataSource | XA DataSource |
| The path to this DataSource in JNDI | Any jndi path, like | mandatory | mandatory | mandatory |
| The implementation class | ex. | mandatory: must implement | mandatory: must implement | mandatory: must implement |
| Properties to pass to the driver | Semi-colon delimited string | optional | optional | mandatory |
| URL for the | ex. | mandatory | mandatory | optional |
| Determines the type of the driver | Defaults to | do not set | do not set |
|
| Determines transaction support type |
| do not set | mandatory | unset defaults to only valid option: |
| Identifier used in configuration files to reference this DataSource | Must contain no path-like characters | optional | optional | optional |
| Username to connect to the database | String | optional | optional | optional |
| Password to connect to the database | String | optional | optional | optional |
JMS resources (such as connection factories, queues or topics) are added through pipe-delimited configuration properties that starts with cargo.resource.resource
. Example:
cargo.resource.resource.jms.cf=cargo.resource.name=jms/cf/MyCf\|cargo.resource.type=javax.jms.ConnectionFactory\|cargo.resource.id=MyCf cargo.resource.resource.jms.queue=cargo.resource.name=jms/MyQueue\|cargo.resource.type=javax.jms.Queue\|cargo.resource.id=MyQueue |
Here are the properties that are valid for this:
c.r
means cargo.resource
Property | Purpose | Valid Values | Mandatory? |
---|---|---|---|
| The ID for the JNDI entry of this JMS resource | ID used in configuration files, if not specified an identifier is created using the name | optional |
| The path to this JMS resource in JNDI | Any JNDI path, like | mandatory |
| Interface of the object | Any JNDI path, like | mandatory |
| Properties to to populate the class with | Semi-colon delimited string; must correspond to setters | optional |
All other resources are added through pipe-delimited configuration properties that starts with cargo.resource.resource
. Example:
cargo.resource.resource1=cargo.resource.name=resource/apple\|cargo.resource.class=org.mycompany.Apple\|... cargo.resource.resource2=cargo.resource.name=resource/pear\|cargo.resource.driver=org.mycompany.Pear\|... |
Here are the properties that are valid for this:
c.r
means cargo.resource
Property | Purpose | Valid Values | Mandatory? |
---|---|---|---|
| The ID for this JNDI entry | ID used in configuration files, if not specified an identifier is created using the name | optional |
| The path to this resource in JNDI | Any JNDI path, like | mandatory |
| Interface of the object | Any valid interface | mandatory |
| The implementation class | Any valid class implementing the interface | mandatory |
| Properties to to populate the class with | Semi-colon delimited string; must correspond to setters | optional |
The Glassfish container has various known issues with regards to DataSource support.
When you try to use GlassFish 3.x or GlassFish 4.x with Derby DataSources, you might run into issues where Glassfish doesn't start, and the Glassfish logs show you messages such as the below:
java.lang.SecurityException: sealing violation: package org.apache.derby is sealed |
This is because Glassfish is already shipped with Derby, and the Glassfish class loaders do not know how to the manage the situation where the same class is duplicated. So, the solution is to simply remove the Derby JAR from dependencies; on the other hand this is not feasible if you are using the same CARGO profile with different containers. Here is how you can work around the issue:
<dependencies> <dependency> <groupId>org.apache.derby</groupId> <artifactId>derby</artifactId> <version>${derby.version}</version> <scope>test</scope> </dependency> </dependencies> ... <build> <plugins> <plugin> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <version>${cargo.version}</version> <!-- This configuration will be used in general. --> <configuration> <container> <dependencies> <dependency> <groupId>org.apache.derby</groupId> <artifactId>derby</artifactId> </dependency> </dependencies> <systemProperties> <derby.system.home>\${project.build.directory}/derby</derby.system.home> </systemProperties> </container> <configuration> <properties> <cargo.datasource.datasource.derby> cargo.datasource.driver=org.apache.derby.jdbc.EmbeddedDriver| cargo.datasource.url=jdbc:derby:derbyDB;create=true| cargo.datasource.jndi=jdbc/CargoDS| cargo.datasource.username=APP| cargo.datasource.password=nonemptypassword </cargo.datasource.datasource.derby> </properties> </configuration> ... </configuration> </plugin> </plugins> </build> <profiles> ... <profile> <id>glassfish3x</id> <build> <pluginManagement> <plugins> <plugin> <groupId>org.codehaus.cargo</groupId> <artifactId>cargo-maven2-plugin</artifactId> <configuration> <container> <containerId>glassfish3x</containerId> <artifactInstaller> <groupId>org.glassfish.main.distributions</groupId> <artifactId>glassfish</artifactId> <version>3.1.2.2</version> </artifactInstaller> <dependencies> <!-- Remove the org.apache.derby dependency since GlassFish 3.x is already shipped with Derby, and adding the dependency twice results in a java.lang.SecurityException: sealing violation: package org.apache.derby. --> <dependency> <groupId>org.apache.derby</groupId> <artifactId>derby</artifactId> <classpath>none</classpath> </dependency> </dependencies> </container> </configuration> </plugin> </plugins> </pluginManagement> </build> </profile> </profiles> |
Users of the Java API can take a look at the following classes as example:
ConfigurationFixtureFactory
: class with static methods showing examples for creating various DataSource and resource types:createDataSource
and createAnotherDataSource
: Creation of a DataSourcecreateDriverConfiguredDataSourceWithLocalTransactionSupport
: Creation of a DataSource with local transaction supportcreateDriverConfiguredDataSourceWithXaTransactionSupport
: Creation of a DataSource with XA transaction supportcreateXADataSourceConfiguredDataSource
: Creation of an XA DataSource as DataSourcecreateConnectionPoolDataSourceAsResource
: Creation of a connection poolcreateXADataSourceAsResource
: Creation of an XA DataSource as a resourcecreateMailSessionAsResource
: Creation of a Mail resourcecreateDataSourceWithWindowsPath
: Creation of a DataSource with a Windows pathcreateJmsQueueAsResource
and createJmsTopicAsResource
: Creation of a JMS queue and topic resource, respectivelyDataSourceOnStandaloneConfigurationTest
: DataSource definition.TransactionEmulationDataSourceOnStandaloneConfigurationTest
: DataSource definition with transaction emulation.XATransactionDataSourceOnStandaloneConfigurationTest
: XA DataSource definition.MailResourceOnStandaloneConfigurationTest
: Resource definition, showing for example mailsession
.JmsQueueResourceOnStandaloneConfigurationTest
and JmsTopicResourceOnStandaloneConfigurationTest
: Resource definition, showing for example a JMS queue and topic, respectively.Users of the Maven2/Maven3 plugin can use the Maven2 Archetype showing DataSource support. Please read: DataSource Definition Archetype.