ID | Chapter | Section | Description | Required | Dependency | Implementation Specific | Defined by | Status | Testable |
Connector:SPEC:200 | 3 | 5 |
The complete set of application server requirements in this specification
is required for a compliant Java EE Connectors Architecture 1.6 container
within an implementation of the Java EE Full Profile.
| true |
| false | technology | active | false |
Connector:SPEC:201 | 3 | 5 |
The minimum set, listed below, must be supported for a compliant
Java EE Connectors Architecture 1.6 container within an
implementation of any subset of the Java EE Full Profile.
....
Based on the availability of other dependent component specification
implementations, the following requirements must be satisfied by a
standalone connector container.
- If a MessageEndpointFactory implementation (such as support for Message
Driven Beans) is available in the standalone implementation, the Message
Inflow requirements specified in Chapter 13, "Message Inflow" must be
satisfied by the standalone connector container implementation.
- If a JTA implementation that is capable of providing support for
distributed XA transactions is provided by the standalone connector
container implementation, the standalone implementation must support
XATransaction resource adapters (see Section 7.14.1, 'Resource Adapter'
on page 7-49).
| true |
| false | technology | active | false |
Connector:SPEC:202 | 3 | 5 |
(further extending off assertion number 201)
If a JTA implementation that is capable of providing support for distributed XA
transactions is provided by the standalone connector container implementation,
the standalone implementation must support XATransaction resource adapters
(see Section 7.14.1, "Resource Adapter" on page 7-49). The standalone container
environment must support a transaction manager that manages transactions
using the JTA XAResource-based contract.
| false |
| false | technology | active | true |
Connector:SPEC:203 | 3 | 5 |
(further extending off assertion number 202)
If a JTA implementation that is capable of providing support for distributed XA
transactions is provided by the standalone connector container implementation,
the standalone implementation must support XATransaction resource adapters
(see Section 7.14.1, "Resource Adapter" on page 7-49). ...
...
The standalone implementation, in this case, must also support Transaction Inflow.
| false |
| false | technology | active | true |
Connector:SPEC:1 | 5 | 3.1 | The ResourceAdapter class is required to be a JavaBean. | true |
| true | technology | active | true |
Connector:SPEC:2 | 5 | 3.1 | In order to bootstrap a resource adapter instance, the application server must use the configured ResourceAdapter JavaBean and call its start method. | true |
| true | technology | active | true |
Connector:SPEC:3 | 5 | 3.1 | The application server must instantiate at least one ResourceAdapter JavaBean per resource adapter deployment.
| true |
| false | technology | active | true |
Connector:SPEC:4 | 5 | 3.1 | During the start method call, an application server must provide a BootstrapContext instance containing references to some of the application server facilities (for example WorkManager) for use by the resource adapter instance.
| true |
| true | technology | active | true |
Connector:SPEC:5 | 5 | 3.2 | Prior to using a ManagedConnectionFactory JavaBean, the application server must create an association between the ManagedConnectionFactory JavaBean and a ResourceAdapter JavaBean, by calling the setResourceAdapter method on the ManagedConnectionFactory JavaBean.
| true |
| false | technology | active | true |
Connector:SPEC:6 | 5 | 3.2 | The setResourceAdapter method on the ManagedConnectionFactory JavaBean must be called exactly once; that is, the association must not change during the lifetime of a Managed-ConnectionFactory JavaBean.
| true |
| false | technology | active | true |
Connector:SPEC:7 | 5 | 3.3 | Prior to using an ActivationSpec JavaBean, the application server must create an association between the ActivationSpec JavaBean and a ResourceAdapter JavaBean, by calling the setResourceAdapter method on the ActivationSpec JavaBean.
| true |
| false | technology | active | true |
Connector:SPEC:8 | 5 | 3.3 | The setResourceAdapter method on the ActivationSpec JavaBean must be called exactly once; that is, the association must not change during the lifetime of an ActivationSpec Java-Bean.
| true |
| false | technology | active | true |
Connector:SPEC:9 | 5 | 3.4 | Irrespective of what causes a resource adapter instance to be shutdown, the application server must use the following two phases to shutdown a resource adapter instance.
Phase one : Before calling the stop method on the ResourceAdapter JavaBean, the application server must ensure that all applications using the specific resource adapter instance are stopped. This guarantees that application threads will not use the resource adapter instance
(even though the resource adapter instance specific objects may still be in the memory heap).
| true |
| false | technology | active | false |
Connector:SPEC:10 | 5 | 3.4 | Irrespective of what causes a resource adapter instance to be shutdown, the application server must use the following two phases to shutdown a resource adapter instance.
Phase Two: The application server calls the stop method on the ResourceAdapter JavaBean to notify the resource adapter instance to stop functioning so that it can be safely unloaded. This is a shutdown notification from the application server, and this method is called by an application
server thread. The application server thread executes in an unspecified context.
| true |
| false | technology | active | false |
Connector:SPEC:11 | 5 | 3.5 | The application server must use a new ResourceAdapter JavaBean for managing the lifecycle of each resource adapter instance, and must not reuse or share a ResourceAdapter JavaBean across multiple resource adapter instances.
| true |
| false | technology | active | true |
Connector:SPEC:12 | 5 | 3.5 | The applcation server thread which calls the start and stop method on the ResourceAdapter JavaBean executes in a unspecified context. However, the application server thread must have at least the same level of security permissions as that of the resource adapter instance.
| true |
| false | technology | active | true |
Connector:SPEC:13 | 5 | 3.6 | The ResourceAdapter JavaBean should be treated as a central authority or registry for re-source adapter instance specific information, and it should have access to the overall state of the resource adapter instance (network endpoints, etc.). | false |
| false | technology | active | false |
Connector:SPEC:14 | 5 | 3.6 | Any resource adapter specific object (for example, ManagedConnectionFactory JavaBean,
ActivationSpec JavaBean or others) which creates network endpoints should register them with the
ResourceAdapter JavaBean.
| false |
| false | technology | active | true |
Connector:SPEC:15 | 5 | 3.6 | The resource adapter threads should periodically scan the ResourceAdapter JavaBean state and behave accordingly. It is desirable that such threads avoid boundless blocking on I/O calls, and instead use a bounded blocking duration. This helps in resource adapter shutdown, and also potentially avoid deadlock situations during shutdown. | false |
| false | technology | active | false |
Connector:SPEC:204 | 5 | 3.7.5 |
If the application server implementation provides an implementation of the Bean
Validation specification, the application server must check the validity of the
configuration settings provided by the deployer for a JavaBean, using the
capabilities provided by the Bean Validation specification.
This validation must be performed before using the JavaBean.
| true |
| false | technology | active | false |
Connector:SPEC:205 | 5 | 3.7.5 |
The application server must support the decoration of the following
JavaBeans with constraint annotations:
- ResourceAdapter
- ManagedConnectionFactory
- ActivationSpec
- Administered Objects
| true |
| false | technology | active | true |
Connector:SPEC:16 | 6 | 2 | An application server should use the connection management contract to implement a connection pooling mechanism in its own implementation-specific way. | false |
| false | technology | active | true |
Connector:SPEC:17 | 6 | 5.1 | A resource adapter is required to implement the equals and hashCode methods defined on the ConnectionRequestInfo interface | true |
| false | technology | active | false |
Connector:SPEC:18 | 6 | 5.1 | A connection implementation class implements its methods in a resource adapter implementation specific way. It must use javax.resource.spi.ManagedConnection instance as its underlying physical connection.
| true |
| false | technology | active | true |
Connector:SPEC:19 | 6 | 5.1 | A resource adapter should only introduce additional getConnection methods if it requires additional flexibility (beyond that offered by the default getConnection method) in the connection request invocations.
| false |
| false | technology | active | true |
Connector:SPEC:20 | 6 | 5.2 | An implementation class for ConnectionManager interface is required to implement the java. io.Serializable interface.
| true |
| false | technology | active | true |
Connector:SPEC:21 | 6 | 5.3 | The equals and hashCode method implementation should be based on a complete set of configuration properties that makes a ManagedConnectionFactory instance unique and specific to an EIS instance.
| false |
| false | technology | active | true |
Connector:SPEC:22 | 6 | 5.4 | Any operations on the ManagedConnection from any previously created connection handles should result in an application level exception.
| false |
| false | technology | active | true |
Connector:SPEC:23 | 6 | 5.4 | The application server should use connection matching contract for ManagedConnection in-stances that have no existing connection handles.
| false |
| false | technology | active | true |
Connector:SPEC:24 | 6 | 5.4 | To avoid any unexpected matching behavior, the application server should not pass a ManagedConnection instance with existing connection handles to the matchManagedConnections method as part of a candidate set.
| false |
| false | technology | active | true |
Connector:SPEC:25 | 6 | 5.4 | An application server should explicitly call ManagedConnection.destroy to destroy a physical connection. An application server should destroy a physical connection to manage the size of its connection pool and to reclaim system resources.
| false |
| false | technology | active | true |
Connector:SPEC:26 | 6 | 8.3 | The application server should call ManagedConnection.cleanup to initiate the connection cleanup.
| false |
| false | technology | active | true |
Connector:SPEC:27 | 6 | 10.1 | A resource adapter must provide implementations of the following interfaces:
javax.resource.spi.ManagedConnectionFactory
javax.resource.spi.ManagedConnection
javax.resource.spi.ManagedConnectionMetaData
| true |
| false | technology | active | false |
Connector:SPEC:28 | 6 | 10.1 | The ManagedConnection implementation provided by a resource adapter must use the following interface and classes to provide support to an application server for connection management (and transaction management, as explained later):
javax.resource.spi.ConnectionEvent
javax.resource.spi.ConnectionEventListener
| true |
| false | technology | active | true |
Connector:SPEC:29 | 6 | 10.1 | A resource adapter is required to provide a default implementation of the javax.resource.spi.ConnectionManager interface.
| true |
| true | technology | active | false |
Connector:SPEC:30 | 6 | 10.2 | An application server must use the interfaces defined in the connection management contract to use services provided by a resource adapter. These interfaces are as follows:
javax.resource.spi.ManagedConnectionFactory
javax.resource.spi.ManagedConnection
javax.resource.spi.ManagedConnectionMetaData
| true |
| false | technology | active | true |
Connector:SPEC:31 | 6 | 10.2 | An application server is required to provide an implementation of the javax.resource.spi.ConnectionManager interface. | true |
| false | technology | active | true |
Connector:SPEC:32 | 6 | 10.2 | An application server is required to implement the javax.resource.spi.-ConnectionEventListener interface and to register ConnectionEventListener with resource adapter to get connection-related event notifications. An application server uses these event notifications to do its pool management, transaction management, and connection cleanup.
| true |
| false | technology | active | true |
Connector:SPEC:33 | 6 | 10.2 | An application server is required to use the following interfaces (supported by the resource adapter) to provide basic error logging and tracing for its configured set of resource adapters: ManagedConnectionFactory.set/getLogWriter ManagedConnection.set/getLogWriter
| true |
| false | technology | active | false |
Connector:SPEC:34 | 6 | 10.2 | An application server is required to use the javax.resource.spi.ConnectionManager hook-in mechanism to provide its specific quality of services.
| true |
| false | technology | active | true |
Connector:SPEC:35 | 6 | 10.2 | The connector specification requires an application server to implement ConnectionEventListener interface and handle local transaction related events. | true |
| false | technology | active | true |
Connector:SPEC:36 | 7 | 3.1 | If the transaction support level for a resource adapter is NoTransaction, an invocation of getXAResource method should throw a ResourceException.
| true |
| false | technology | active | false |
Connector:SPEC:37 | 7 | 6.2 | If a XAResource.prepare method is called on a RM that supports only one-phase commit, then the RM should throw an XAException with XAER_PROTO or XA_RB* flag.
| false |
| false | technology | active | false |
Connector:SPEC:38 | 7 | 6.2 | The RM should discard its knowledge of the branch only when the TM calls XAResource.forget. RM is required to notify the TM of all heuristic decisions.
| false |
| false | technology | active | false |
Connector:SPEC:39 | 7 | 6.2 | If RMsupports a XAResource contract, then it is required to support the one-phase commit protocol by implementing XAResource.commit when the boolean flag onePhase is set to True.
| true |
| false | technology | active | false |
Connector:SPEC:40 | 7 | 6.2 | If RM supports 2PC, then its implementation of 2PC is required to be compliant with 2PC protocol definition with presumed rollback as specified in the OSI DTP specification.
| true |
| false | technology | active | false |
Connector:SPEC:41 | 7 | 6.2 | The RM XAResource implementation is required to support XAResource.start and XAResource.end for association and disassociation of a transaction (as represented by unique XID) with recoverable units of work being done on the RM.
| true |
| true | technology | active | true |
Connector:SPEC:42 | 7 | 6.2 | Resource adapter is required to send local transaction events through the Connection-EventListener interface when an application component starts a local transaction using application level transaction demarcation interface.
| true |
| true | technology | active | true |
Connector:SPEC:43 | 7 | 6.2 | Application server is required to use local transaction in a scenario where the following
conditions hold:
Multiple components use a single resource adapter that is local transaction capable
Components get connections to the same EIS instance Components have not specified res-sharing-scope flag as unshareable. This condition accounts for potential shareability of connections in terms of security context. client-specific connection parameters and EIS specific configuration.
| true |
| false | technology | active | true |
Connector:SPEC:44 | 7 | 6.2 | The container is required to provide a mechanism to change the association of a connection handle to different ManagedConnection instances depending on the connection sharing and transaction scope. This mechanism is used in scenarios where components hold on to connec- tion handles across different local transaction and connection sharing scopes.
| true |
| false | technology | active | true |
Connector:SPEC:45 | 7 | 6.2 | The resource adapter is required to implement the associateConnection method to support connection sharing.
| false |
| false | technology | active | false |
Connector:SPEC:46 | 7 | 6.3 | TM must use the XAResource interface supported by an RM for transaction coordination and recovery.
| true |
| false | technology | active | true |
Connector:SPEC:47 | 7 | 6.3 | TM must assume that it can support RMs that have different capabilities as allowed by the RM requirements specification section RMs that make heuristic decisions and RMs that use the read-only optimization.
| true |
| false | technology | active | false |
Connector:SPEC:48 | 7 | 6.3 | TM s support of one-phase commit protocol optimization is required.
| true |
| false | technology | active | true |
Connector:SPEC:49 | 7 | 6.3 | In this optimization, the TM makes its phase 2 commit request to that RM without having made a phase 1 prepare request.
| true |
| false | technology | active | false |
Connector:SPEC:50 | 7 | 9 | Containers should assume connections to be shareable if no deployment hint is provided. Refer to EJB specification and the Servlet specification for a description of the deployment descriptor element.
| false |
| false | technology | active | true |
Connector:SPEC:51 | 7 | 11 | The associateConnection method implementation for a ManagedConnection should disso-ciate the connection handle (passed as a parameter) from its currently associated ManagedConnection and associate the new connection handle with itself. | false |
| false | technology | active | true |
Connector:SPEC:52 | 7 | 13.2 | An application server is required to support resource adapters with all three levels of transac-tion support NoTransaction, LocalTransaction, and XATransaction.
| true |
| false | technology | active | true |
Connector:SPEC:206 | 7 | 13 | For ManagedConnectionFactory JavaBeans that implement the
TransactionSupport interface, the application server must
perform the following prior to using the JavaBean.
-. The application server must call the getTransactionSupport method
to determine its level of transaction support.
-. The application server must complete the configuration of the
ManagedConnectionFactory instance (see Section 5.3.2
"ManagedConnectionFactory JavaBean and Outbound Communication")
before invoking the getTransactionSupport method.
-. The application server must use the value returned by the
getTransactionSupport method.
-. The application server must provide the transaction levels listed
in TransactionSupport.TransactionSupportLevel enum,
| true |
| false | technology | active | true |
Connector:SPEC:207 | 7 | 13 | A resource adapter must always return a level of transaction support
that is equal to or lesser than the resource adapter's transaction
support classification.
| true |
| false | technology | active | false |
Connector:SPEC:53 | 7 | 13.2 | The application server is required to use the LocalTransaction interface-based contract to manage local transactions for a resource manager.
| true |
| false | technology | active | true |
Connector:SPEC:54 | 7 | 13.2 | The application server is required to support a transaction manager that manages transactions using the JTA XAResource-based contract. The requirements for a transaction manager to support an XAResource-based contract are specified in section 7.6.3 on page 83.
| true |
| false | technology | active | true |
Connector:SPEC:55 | 7 | 15.2 |
The application server must use the deployment descriptor mechanism
and the values in the Connector metadata annotation to ascertain the
transactional capabilities of a resource adapter.
| true |
| false | technology | active | true |
Connector:SPEC:56 | 7 | 13.2 | The application server is required to implement the javax.resource.spi.-ConnectionEventListener interface to get transaction-related event notifications.
| true |
| false | technology | active | true |
Connector:SPEC:291 | 7 | 14 |
The application server is required to make a TransactionSynchronizationRegistry
object available via its BootstrapContext implementation.i
| true |
| false | technology | active | true |
Connector:SPEC:288 | 9 | 1.5.1 |
If an application server supports the deployment of a resource adapter which
supports GSSCredential as part of the security contract, the application server
must provide an implementation of the GSSCredential interface
| true |
| false | technology | active | false |
Connector:SPEC:289 | 9 | 2.1 |
The resource adapter must specify its support for the security
contract as part of its deployment descriptor or through metadata
annotations.
| true |
| false | technology | active | false |
Connector:SPEC:290 | 9 | 2.1 |
If the security information provided by the component or the container is not
adequate to authenticate the caller, or if the security information is erroneous, the
resource adapter must throw a SecurityException to indicate the error
condition.
| true |
| false | technology | active | false |
Connector:SPEC:57 | 9 | 1.3 |
An application server should use the Principal interface (or any
derived interface) to pass a resource principal as part of a
Subject to a resource adapter.
| false |
| false | technology | active | true |
Connector:SPEC:58 | 9 | 1.4 | The mechanism type definition for GenericCredential must be consistent with the Object Identifier (OID) based representation specified in the GSS [5] specification. In the GenericCredential interface, the mechanism type is returned as a stringified representation of the OID specification.
| false |
| false | technology | active | false |
Connector:SPEC:59 | 9 | 1.8.1 | In case of Kerberos mechanism type, the application server must pass the principal s TGT (ticket granting ticket) to a resource adapter in a private credential set.
| false |
| false | technology | active | true |
Connector:SPEC:60 | 9 | 3 | Resource adapter is required to support the security contract by implementing the method ManagedConnectionFactory.createManagedConnection.
| false |
| false | technology | active | true |
Connector:SPEC:61 | 9 | 3 |
Resource adapter is required to specify its support for the security contract
as part of its deployment descriptor or through metadata annotations.. The
relevant deployment descriptor elements are [refer section 15.6 for a detailed
specification]: authentication-mechanism, authentication-mechanism- type,
reauthentication-support and credential-interface.
| true |
| false | technology | active | true |
Connector:SPEC:62 | 9 | 3 | Application server is required to use the method ManagedConnectionFactory.createManagedConnection to pass the security context to the resource adapter during EIS sign-on.
| true |
| false | technology | active | true |
Connector:SPEC:63 | 9 | 3 | Application server is required to be capable of using options - A and C - as specified in the
section 9.2.6 for the security contract.
| true |
| false | technology | active | true |
Connector:SPEC:64 | 9 | 3 | Application server is required to implement the method allocateConnection in its ConnectionManager implementation.
| true |
| false | technology | active | true |
Connector:SPEC:65 | 9 | 3 | Application server is required to configure its use of the security contract based on the security requirements specified by the resource adapter in its deployment descriptor. For example, if a resource adapter specifies that it supports only BasicPassword authentication,
application server should use the security contract to pass PasswordCredential instance to the resource adapter.
| true |
| false | technology | active | true |
Connector:SPEC:66 | 10 | 3 |
The application server is required to use threads of the same thread
priority level to process Work instances submitted by a specific
resource adapter.
| true |
| false | technology | active | false |
Connector:SPEC:67 | 10 | 3.1 |
The application server is required to use threads of the same thread
priority level to process Work instances submitted by a specific
resource adapter.
| false |
| false | technology | active | false |
Connector:SPEC:68 | 10 | 3.3.6 | Both run and release methods in Work implementation must be declared as non-synchronized methods.
| true |
| false | technology | active | false |
Connector:SPEC:69 | 10 | 3.3 | The optional startTimeout parameter specifies a time duration (in milliseconds) within which the execution of the Work instance must start. Otherwise, the Work instance is rejected with a WorkRejectedException set to an appropriate error code (WorkException. START_TIMED_OUT).
| true |
| false | technology | active | false |
Connector:SPEC:70 | 10 | 3.3.6 | The application server is required to implement the WorkManager interface.
| true |
| false | technology | active | true |
Connector:SPEC:71 | 10 | 3.3.6 | The application server must allow nested Work submissions. | true |
| false | technology | active | true |
Connector:SPEC:72 | 10 | 3.3.6 | When the application server is unable to recreate an execution context (if it is specified) for the submitted Work instance, it must throw a WorkCompletedException set to an appropriate error code.
| true |
| false | technology | active | true |
Connector:SPEC:73 | 10 | 3.3.6 | The WorkManager must catch any exception thrown during Work processing (which includes execution context setup) and wrap it with a WorkCompletedException set to an appropriate error code (indicates nature of the error condition).
| true |
| false | technology | active | true |
Connector:SPEC:74 | 10 | 3.3.6 | The application server must execute a submitted Work instance with an unspecified context (if no execution context has been specified), or must execute it with the specified execution context. That is, a submitted Work instance must never inherit the submitter s execution context when no execution context is specified.
| true |
| false | technology | active | false |
Connector:SPEC:75 | 10 | 3.3.6 | If the application server is unable to start Work execution (when a start timeout is specified) for the submitted Work instance, it should reject the Work instance with a WorkRejectedException set to an error code (WorkException.START_TIMED_OUT). | true |
| false | technology | active | false |
Connector:SPEC:76 | 10 | 3.3.6 | The application server must use a value -1 (WorkManager.UNKNOWN) to indicate an unknown Work start delay duration. | true |
| false | technology | active | true |
Connector:SPEC:77 | 10 | 3.3 | When a WorkListener is provided by the resource adapter, the appli-cation server must send event notifications to the WorkListener.
| true |
| false | technology | active | true |
Connector:SPEC:78 | 10 | 3.3 | The WorkListener instance must not make any thread assumptions and must be thread-safe; that is, a notification can occur from any arbitrary thread with an unspecified context
| true |
| false | technology | active | false |
Connector:SPEC:79 | 10 | 3.3 | The WorkListener must not make any assumptions on the ordering of notifications.
| true |
| false | technology | active | false |
Connector:SPEC:80 | 10 | 3.5 | An application server is required to provide a new java.util.Timer instance or an unshared (that is, no one else has a reference) instance with an empty task queue, for each call on createTimer method on the BootstrapContext instance.
| true |
| false | technology | active | true |
Connector:SPEC:81 | 10 | 3.5 | The resource adapter should instead use the BootstrapContext instance provided by the application server to obtain a Timer instance. | false |
| false | technology | active | true |
Connector:SPEC:245 | 10 | 3.10 |
The application server must establish an association between the
resource adapter instance and the Work instance before the exection
of the Work instance has been started (Refer Section 10.3.3.4,
'Work Started' on page 10-13).
| true |
| true | technology | active | true |
Connector:SPEC:246 | 10 | 3.10 |
When a Work instance has been distributed to a new WorkManager
instance (for example, as in Section 10.3.11 'Distributed Work
processing'), the resource adapter instance that is associated
with the Work instance must be available in the WorkManager instance
that the Work has been distributed to. This allows the Work instance
to use application server facilities like WorkManager, MessageEndpointFactory
etc that are specific to the instance that the Work has been distributed to.
| true |
| false | technology | active | false |
Connector:SPEC:247 | 10 | 3.11.1 |
Work instances that may be distributed by a WorkManager must implement
the DistributableWork interface.
| true |
| false | technology | active | false |
Connector:SPEC:248 | 10 | 3.11.1 |
A Work instance that implements the DistributableWork interface
must not have any reference to local resourceadapter state. This
allows the WorkManager to delegate processing of the Work instance
to a different WorkManager instance that is running in a different
Java virtual machine.
| true |
| false | technology | active | false |
Connector:SPEC:249 | 10 | 3.11.1 |
All artifacts that may be coupled to the application server instance
where the Work is executed in, must be obtained through the ResourceAdapterAssociation
mechanism discussed in Section 10.3.10 'Resource Adapter association'.
| true |
| false | technology | active | false |
Connector:SPEC:250 | 10 | 3.11.2 |
A WorkManager implementation that supports the submission of
DistributableWork instances must implement the DistributableWorkManager
marker interface. This allows the resource adapter to programmatically
determine whether the WorkManager supports the submission of DistributableWork
instances.
| false |
| true | technology | active | true |
Connector:SPEC:251 | 10 | 3.11.2 |
The application server that supports DistributableWorkManager along with
inputs from the administrator and deployer,must ensure that the environment
made available to the DistributableWork instance is consistent irrespective of
whether the DistributableWork instance is executed in a local or remote manner.
| true |
| false | technology | active | false |
Connector:SPEC:252 | 10 | 3.11.3 |
When a DistributableWork instance is submitted to a WorkManager that
does not implement DistributableWorkManager interface, the WorkManager
must execute the Work locally.
| true |
| false | technology | active | false |
Connector:SPEC:254 | 10 | 3.11.3 |
A DistributableWorkManager must support the requirements in Chapter 11,
'Generic Inflow Context' and Chapter 16, 'Security Inflow'.
| true |
| false | technology | active | false |
Connector:SPEC:208 | 11 | 3.1 |
Transaction and Security inflow contexts are standardised via the
TransactionContext and SecurityContext interfaces. The
propagation of Quality of Service hints to a WorkManager for the execution of a
Work instance is standardized through the HintsContext interface. The
application server must support both these inflow contexts.
| true |
| false | technology | active | true |
Connector:SPEC:255 | 11 | 3.2 |
The application server must support the establishment of
TransactionContext, SecurityContext and
HintsContext contexts.
| true |
| false | technology | active | false |
Connector:SPEC:209 | 11 | 3.2 |
The application server must support the WorkContext interface.
If a resource adapter submits a Work instance implementing the
WorkContextProvider interface, the application server must use
the WorkContexts provided by the resource adapter to assign the
execution context for that Work instance.
| true |
| false | technology | active | true |
Connector:SPEC:210 | 11 | 4 | Since nested Work submissions are allowed in the Connector
WorkManager ( see Section 10.3.3 "WorkManager Interface" ), the
Connector WorkManager must support nested contexts, unless the
WorkContext type prohibits it .
| true |
| false | technology | active | true |
Connector:SPEC:211 | 11 | 4.1 |
The application server must check if all of the WorkContext types declared by
the resource adapter is supported by the application server during resource adapter
deployment. The application server must employ an exact type equality check (that
is java.lang.Class.equals(java.lang.Class) check) to check for the
support.
| true |
| false | technology | active | false |
Connector:SPEC:256 | 11 | 4.1 |
If the application server cannot support one or more of the WorkContext
types declared in required-inflow-context elements, it must fail deployment
of the resource adapter.
| true |
| false | technology | active | false |
Connector:SPEC:212 | 11 | 4.2 |
The application server must employ an exact type equality check (that
is java.lang.Class.equals(java.lang.Class) check) in isContextSupported,
to check if it supports the WorkContext type provided by the resource
adapter.)
| true |
| false | technology | active | false |
Connector:SPEC:213 | 11 | 4.2 |
For WorkContext classes that are defined as abstact classes (like
SecurityContext - see Section 16.4 "SecurityContext Class"), the
resource adapter must use the abstract class while invoking isContextSupported
method and not its implementation class.
| true |
| false | technology | active | false |
Connector:SPEC:257 | 11 | 4.2 |
For custom extensions of the standard WorkContexts, the resource adapter
must always check support for the most specific WorkContext first.
| true |
| false | technology | active | false |
Connector:SPEC:214 | 11 | 4.3 |
As specified in Section 10.3.4 "WorkListener Interface and WorkEvent Class",
the WorkManager must catch any exception thrown during Work processing, which
includes execution context setup (including Section 11.4.2 "Checking Support
for an WorkContext Type"), and wrap it with a WorkCompletedException set to an
appropriate error code defined in WorkContextErrorCodes, which indicates the
nature of the error condition.
| true |
| false | technology | active | true |
Connector:SPEC:215 | 11 | 4.3 |
Since not all the WorkContext instances provided by the resource
adapter may be supported by the application server, the application
server must check to ensure that the WorkContexts provided by the
resource adapter are supported by the application server.
| true |
| false | technology | active | true |
Connector:SPEC:216 | 11 | 4.3 |
The app server must also check to ensure that the WorkContexts
provided by the resource adapter do not have duplicates. For instance,
a resource adapter must not be able to submit two instances of the
TransactionContext class. The application server must ensure
that more than one WorkContexts provided by the resource adapter,
do not implement the same WorkContext type supported by the app server.
| true |
| false | technology | active | true |
Connector:SPEC:217 | 11 | 4.3 |
The application server must employ a java.lang.Class.isAssignable(
java.lang.Class) style check. Specifically, this method must check
whether an WorkContext class that is supported by the application
server, can be converted to the type provided by the resource adapter,
via an identity conversion or via a widening reference conversion.
| true |
| false | technology | active | true |
Connector:SPEC:218 | 11 | 4.3 |
If a particular WorkContext type provided by the resource adapter
is supported by the application server, the application server must
use the WorkContext as-is and not attempt to use it as a supported
parent type. That is, an application server must use the most specific
WorkContext type it supports.
| true |
| false | technology | active | true |
Connector:SPEC:219 | 11 | 4.3 |
If a particular WorkContext type provided by the resource adapter
is not supported by the application server, the application server
must assume that it can safely fallback to a superclass(excluding
the WorkContext interface) that is supported by it.
| true |
| false | technology | active | true |
Connector:SPEC:258 | 11 | 4.3 |
If the above conditions** are not met, the application server must
fail the Work submission with a WorkCompletedException with an
appropriate error code, to indicate the nature of the error condition.
** The "above conditions" would include all assertion checks for:
Connector:SPEC:214
Connector:SPEC:215
Connector:SPEC:216
Connector:SPEC:217
Connector:SPEC:218
Connector:SPEC:219
| true |
| false | technology | active | true |
Connector:SPEC:220 | 11 | 5 |
The TransactionContext class extends the ExecutionContext class (
see Section 10.3.5 "ExecutionContext Class" ). It represents the standard interface a
resource adapter can use to propagate transaction context information from the EIS
to the application server. The Work instance and any message deliveries to
MessageEndpoints in that Work instance must all be carried out in the context of
the transaction context provided by the TransactionContext class.
| true |
| false | technology | active | true |
Connector:SPEC:221 | 11 | 5 |
A resource adapter must not submit a Work that implements
WorkContextProvider along with a valid ExecutionContext to a Connector
WorkManager. When such a Work instance is submitted to the Connector
WorkManager for execution, the application server must detect this scenario and
throw a WorkRejectedException to indicate this error scenario.
| true |
| false | technology | active | true |
Connector:SPEC:259 | 11 | 6 |
The resource adapter may use the setHint method to set a Hint in the
context. It must use a non-Null hintName while calling the setHint method.
| true |
| false | technology | active | false |
Connector:SPEC:260 | 11 | 6 |
Resource adapters and application servers must not use 'javax.resource.'-prefixed
names for their custom requirements.
| true |
| false | technology | active | false |
Connector:SPEC:261 | 11 | 6 |
The WorkManager must ignore any unknown hint name-value pairs
submitted by a resource adapter instance.
| true |
| false | technology | active | true |
Connector:SPEC:222 | 11 | 7 |
When a WorkManager sets up the execution context of a Work instance that
implements WorkContextProvider, the WorkManager must make the relevant
lifecycle notifications if an WorkContext instance implements this interface.
The possible error conditions that might occur while associating an WorkContext
with a Work instance is captured in WorkContextErrorCodes. The
WorkManager must call the contextSetupFailed method with the appropriate
error code in WorkContextErrorCodes.
| true |
| false | technology | active | true |
Connector:SPEC:223 | 11 | 7 |
When a Work instance is submitted to the Connector WorkManager using
one of the methods that passes in a WorkListener as a parameter, the
WorkManager must send Work related notifications to the WorkListener
and WorkContext setup related notifications to the
WorkContextLifecycleListener interface.
| true |
| false | technology | active | true |
Connector:SPEC:224 | 11 | 7 |
The WorkManager must make the notifications related to Work accepted
and started events prior to calling the WorkContext setup related
notifications. The order of setup related notifications of WorkContext
types within a list of inflow contexts, of a Work instance, is undefined.
| true |
| false | technology | active | true |
Connector:SPEC:225 | 11 | 7 |
The WorkManager must make the notifications related to Work accepted
and started events prior to calling the WorkContext setup related
notifications.
| true |
| false | technology | active | true |
Connector:SPEC:262 | 11 | 7 |
The WorkManager must make the notifications related to the Work
completed event after the WorkContext setup related
notifications.
| true |
| false | technology | active | true |
Connector:SPEC:82 | 13 | 3 | The message delivery preferences must not change during the lifetime of a message endpoint.
| true |
| false | technology | active | true |
Connector:SPEC:83 | 13 | 3 | A resource adapter capable of message delivery to message endpoints must provide an ActivationSpec JavaBean class for each supported endpoint message listener type.
| true |
| false | technology | active | false |
Connector:SPEC:319 | 13 | 3 |
The MessageEndpointFactory also provides the unique name for the
message endpoint deployment that it represents. . If the message
endpoint has been deployed into a clustered application server,
then the application server must provide the same name for that
message endpoints activation in each application server instance.
| false |
| false | technology | active | false |
Connector:SPEC:263 | 13 | 4.2.2 |
If the application server provides an implementation of the BeanValidation
specification (See "Bean Validation" on page F-2), the application server must check
the validity of the configuration settings provided by the deployer for a JavaBean,
using the capabilities provided by the Bean Validation specification before calling
the validate method.
| true |
| true | technology | active | true |
Connector:SPEC:264 | 13 | 4.2.4 |
The application server is required to merge values specified via
annotations and deployment descriptors as specified in Section 18.3,
'Deployment Descriptors and Annotations' on page 18-2, before applying
the administed object class configuration properties.
| true |
| false | technology | active | true |
Connector:SPEC:84 | 13 | 4.4 | The application server must notify the resource adapter via the XAResource instance if a message delivery is transacted.
| true |
| false | technology | active | true |
Connector:SPEC:85 | 13 | 4.4 | When an endpoint is deactivated, the application server notifies the resource adapter via the endpointDeactivation method call. The application server must pass the same MessageEndpointFactory instance and the ActivationSpec JavaBean instance that was used dur-ing the endpoint activation.
| true |
| false | technology | active | false |
Connector:SPEC:320 | 13 | 4.4 |
The application server must make the application component environment
namespace of the endpoint (that is being activated), available to the
resource adapter during the call to the endpointActivation method.
| true |
| false | technology | active | true |
Connector:SPEC:86 | 13 | 4.7 |
A resource adapter that is capable of delivering messages to
message endpoints must provide a list of endpoint message
listener types it supports, and also must provide an ActivationSpec
JavaBean class for each message listener type it supports. This
information must be part of the resource adapter deployment descriptor.
| true |
| false | technology | active | false |
Connector:SPEC:87 | 13 | 4.7 | ActivationSpec and administered objects are required to be a JavaBean.
| true |
| false | technology | active | false |
Connector:SPEC:88 | 13 | 4.7 | A resource adapter must allow an application server to make concurrent endPointActivation method or endpointDeactivation method calls.
| true |
| false | technology | active | false |
Connector:SPEC:89 | 13 | 4.7 | The endpoint application s "activation-config" properties (specified in the endpoint deployment descriptor) should be a subset of the ActivationSpec JavaBean s properties. There must be a one-to-one correspondence between the "activation-config" property names and the
ActivationSpec JavaBean s property names. This allows a deploy tool to auto-merge the "activation-config" properties with an ActivationSpec JavaBean instance. Any specified "activation-config" property which does not have a matching property in the ActivationSpec
JavaBean should be treated as an error.
| true |
| false | technology | active | false |
Connector:SPEC:90 | 13 | 4.7 | All deployed endpoints must be automatically reactivated by the application server when it restarts after a normal shutdown or system crash.
| true |
| false | technology | active | false |
Connector:SPEC:91 | 13 | 4.7 | Before a resource adapter is undeployed, the application server is required to deactivate all active endpoints consuming messages from that specific resource adapter.
| true |
| false | technology | active | false |
Connector:SPEC:92 | 13 | 4.9 | The application server is required to supply a unique MessageEndpointFactory instance for each activation. | true |
| false | technology | active | true |
Connector:SPEC:93 | 13 | 4.9 | A MessageEndpointFactory must not override the default java.lang.Object.equals method. This ensures that each MessageEndpointFactory JavaBean is treated uniquely (based on the implicit Java object identity).
| true |
| false | technology | active | true |
Connector:SPEC:94 | 13 | 4.9 | The resource adapter should treat multiple endpoints with similar activation information separately and guarantee message delivery semantics.
| true |
| false | technology | active | false |
Connector:SPEC:95 | 13 | 4.9 |
The resource adapter must treat each ActivationSpec JavaBean uniquely
irrespective of its contents. That is, the resource adapter must not treat two
separate ActivationSpec JavaBeans as equals.
| true |
| false | technology | active | true |
Connector:SPEC:96 | 13 | 4.9 | The application server's proxy endpoint instance is required to implement the endpoint message listener type and the Endpoint interface. | true |
| false | technology | active | true |
Connector:SPEC:97 | 13 | 5 | Any attempted use of the proxy endpoint (after its release method is called) must result in a java.lang.IllegalStateException (thrown by the application server).
| true |
| false | technology | active | false |
Connector:SPEC:98 | 13 | 5.1 | The application server must pass by reference all the method parameter objects passed by the resource adapter during a message delivery method call on a proxy endpoint. The application server must not copy or clone the passed method parameter objects during message delivery to the actual
endpoint instance. | true |
| false | technology | active | true |
Connector:SPEC:99 | 13 | 5.1 | If the application server starts a new transaction (depending on endpoint preferences) before delivering a message to an endpoint instance, it must send all transaction notifications to the XAResource instance optionally supplied by the resource adapter as part of the createEndPoint method call.
| true |
| false | technology | active | true |
Connector:SPEC:100 | 13 | 5.1 | A resource adapter must not attempt to deliver messages concurrently to a single endpoint instance.
| true |
| false | technology | active | false |
Connector:SPEC:101 | 13 | 5.1 | The application server must reject concurrent usage of an endpoint instance. | true |
| false | technology | active | true |
Connector:SPEC:102 | 13 | 5.2 | The application server must restart resource adapter instances by calling the start method on each
persisted ResourceAdapter JavaBean, each corresponding to a resource adapter instance that was
active prior to the crash.
| true |
| false | technology | active | false |
Connector:SPEC:103 | 13 | 5.2 | The application server must call the getXAResources method on each ResourceAdapter JavaBean, and
pass in an array of ActivationSpec JavaBeans, each of which corresponds to a deployed endpoint application that was active prior to the system crash.
| true |
| false | technology | active | false |
Connector:SPEC:104 | 13 | 5.2 | Upon being called by the application server during crash recovery (via the getXAResources method),
the resource adapter must return an array of XAResource objects, each of which represents a unique
resource manager. | true |
| false | technology | active | false |
Connector:SPEC:105 | 13 | 5.2 | Since it is possible that multiple resource adapters may use the same resource manager, there may
be more than one XAResource object in the collection representing a resource manager. The
application server may still need to narrow the collection of XAResource objects to a unique set of
resource managers, by using the isSameRM method on the XAResource object.
| false |
| false | technology | active | false |
Connector:SPEC:106 | 13 | 5.2 | The application server must use the XAResource objects to query each resource manager for a list of
indoubt (in an already prepared state awaiting a commit decision) transactions. Then, it must
complete each pending transaction by sending the commit decision to the participating resource
managers.
| true |
| false | technology | active | false |
Connector:SPEC:107 | 13 | 5.7 | The application server is required to propagate any exception thrown during a message delivery to
the resource adapter irrespective of whether the delivery is transacted or not.
| true |
| false | technology | active | true |
Connector:SPEC:108 | 13 | 5.7 | A resource adapter capable of message delivery to message endpoints must provide an ActivationSpec
JavaBean class for each supported endpoint message listener type.
| true |
| false | technology | active | false |
Connector:SPEC:109 | 13 | 5.7 | The resource adapter is expected to know the endpoint message listener type (either by using the ActivationSpec JavaBean contents or based on the ActivationSpec JavaBean class) and deliver messages to the endpoint.
| true |
| false | technology | active | false |
Connector:SPEC:110 | 13 | 5.7 | Note, the ActivationSpec JavaBean instance must not make any assumptions about the availability of
a live resource adapter instance.
| true |
| false | technology | active | false |
Connector:SPEC:111 | 13 | 5.7 | The application server must notify the resource adapter via the XAResource instance if a message delivery is transacted.
| true |
| false | technology | active | true |
Connector:SPEC:112 | 13 | 5.7 | The application server must wrap such an unchecked exception within a javax.ejb.EJBException (which is a java.lang.RuntimeException)
and throw the javax.ejb.EJBException to the resource adapter.
| true |
| false | technology | active | true |
Connector:SPEC:113 | 13 | 5.7 | The resource adapter must treat multiple endpoint activations with similar activation configuration separately.
| true |
| false | technology | active | false |
Connector:SPEC:114 | 13 | 5.7 | The application server must return a new or an unused endpoint instance for every createEndPoint method call on a MessageEndpointFactory.
| true |
| false | technology | active | true |
Connector:SPEC:115 | 13 | 5.9 | In the case where endpoint requires a transcated delivery and there is a imported transaction (source managed transaction) then the container must use the source managed transaction to do the transacted delivery.
The container must ignore the XAResource supplied by the resource adapter if any.
| true |
| false | technology | active | true |
Connector:SPEC:116 | 13 | 5.9 | In the case where endpoint does not require a transcated delivery and there is a imported transaction (source managed transaction) the contaier must suspend the soruce managed transaction. The container must igonre the XAResource supplied by the resource adapter if any.
| true |
| false | technology | active | true |
Connector:SPEC:117 | 13 | 5.9 | In the case where endpoint requires a transcated delivery and there is a no imported transaction (source managed transaction) the container must start a new transaction before making the delivery call. The container must use the XAResource supplied by the resource adapter If any.
| true |
| false | technology | active | true |
Connector:SPEC:118 | 13 | 5.9 | In the case where endpoint does not require a transcated delivery and there is no imported transaction (source managed transaction) the conainer doesnt start a transaction (because the endpoint doesnt need a transacted delivery).
| true |
| false | technology | active | true |
Connector:SPEC:119 | 13 | 5.9 | The application server is required to propagate any exception thrown during a message delivery to the resource adapter irrespective of whether the delivery is transacted or not.
| true |
| false | technology | active | true |
Connector:SPEC:226 | 13 | 4.2.3 |
An administered object may implement the ResourceAdapterAssociation
interface to associate a resource adapter instance with the administered
object.The ResourceAdapterAssociation interface specifies the methods to
associate a administered object JavaBean with a ResourceAdapter JavaBean.
Prior to using the administered object, the application server must
create an association between the administered object and a ResourceAdapter
JavaBean, by calling the setResourceAdapter method on the administered
object. A successful association is established only when the
setResourceAdapter method on the administered object returns without
throwing an exception.
| true |
| false | technology | active | true |
Connector:SPEC:227 | 13 | 4.2.3 |
The setResourceAdapter method on the administered object must be called
exactly once; that is, the association must not change during the
lifetime of a administered object.
| true |
| false | technology | active | true |
Connector:SPEC:228 | 13 | 4.2.3 |
An administered object instance, that implements ResourceAdapterAssociation
interface must ensure that its Java class and the interface type implements
javax.resource.Referenceable and java.io.Serializable interfaces.a
| true |
| false | technology | active | false |
Connector:SPEC:120 | 15 | 4.4 | An application server is required to implement the transaction inflow contract. That is, it must
allow Work submissions with a transaction context (that is, Xid), and provide a valid XATerminator
instance when called via getXATerminator method on the BootstrapContext instance.
| true |
| false | technology | active | true |
Connector:SPEC:121 | 15 | 4.4 | A resource adapter may optionally choose to use the transaction inflow contract. But, a resource
adapter that uses the transaction inflow contract to import an EIS transaction and do transactional
work must implement the prescribed transaction inflow contract. | true |
| false | technology | active | false |
Connector:SPEC:122 | 15 | 4.4 | The XATerminator instance provided by the application server must be thread-safe and re-entrant.
The resource adapter may use an XATerminator instance across different transactions concurrently.
| true |
| false | technology | active | false |
Connector:SPEC:123 | 15 | 4.4 | When the application server is unable to recreate the transaction context (if any) specified for
a Work instance, it must throw a WorkCompletedException (set to an error code
WorkException.TX_RECREATE_FAILED).
| true |
| false | technology | active | true |
Connector:SPEC:124 | 15 | 4.4 | For a particular imported transaction, at any given time, there must be at most one Work instance
that is associated with the transaction. The associated Work instance may be in any state (waiting
for execution to begin or already executing). However, it must be possible for several Work
instances to do work in a transaction (as long as there is at most one Work instance associated
with the transaction at any time). It must also be possible for different resource adapters to be
participating in the same transaction.
| true |
| false | technology | active | false |
Connector:SPEC:125 | 15 | 4.4 | The application server must disallow Work submissions with a
WorkCompletedException (set to an error code WorkException.TX_CONCURRENT_WORK_DISALLOWED), if there
is already a Work instance associated with the transaction (based on whether the , irrespective of
which resource adapter is involved in the Work submission. This determination must be done using
the getGlobalTransactionId method on the Xid object present in the execution context of the
submitted Work instance; the Xid s branch identifier must be ignored. The application server must
not try to serialize Work processing based on transaction information.
| true |
| false | technology | active | true |
Connector:SPEC:126 | 15 | 4.4 | The application server must reject transaction completion or crash recovery calls (with a
javax.transaction.xa.XAException) when a Work instance associated with the transaction is present
and must not block or serialize transaction completion or crash recovery calls waiting for a Work
instance associated with the transaction to complete.
| true |
| false | technology | active | true |
Connector:SPEC:127 | 15 | 4.4 | The application server must reject transaction completion or crash recovery calls with a
javax.transaction.xa.XAException upon any errors.
| true |
| false | technology | active | false |
Connector:SPEC:128 | 15 | 4.4 | The application server should recover the state of all in-doubt transactions upon failure
recovery. | true |
| false | technology | active | false |
Connector:SPEC:129 | 17 | 5.1.1 | An implementation class for ConnectionFactory is required to implement the java.io.Se-rializable interface to support JNDI registration.
| false |
| false | technology | active | false |
Connector:SPEC:130 | 17 | 5.1 | A ConnectionFactory implementation class is also required to implement javax.resource.Referenceable.
| false |
| false | technology | active | false |
Connector:SPEC:131 | 17 | 5.1 | An implementation class for ConnectionFactory is required to provide a default constructor.
| false |
| false | technology | active | true |
Connector:SPEC:132 | 17 | 5.2 | The properties on the ConnectionSpec implementation class must be defined through the getter and setter methods pattern.
| false |
| false | technology | active | true |
Connector:SPEC:133 | 17 | 5.2 | If a resource adapter does not allow a component to demarcate local transactions using LocalTransaction interface, then the method getLocalTransaction must throw a NotSupportedException.
| false |
| false | technology | active | true |
Connector:SPEC:134 | 17 | 5.2 | The properties on the InteractionSpec implementation class must be defined through the getter and
setter methods pattern.
| false |
| false | technology | active | true |
Connector:SPEC:135 | 17 | 5.3 | The properties on the InteractionSpec implementation class must be defined through the getter and
setter methods pattern.
| false |
| false | technology | active | true |
Connector:SPEC:136 | 17 | 5.3 | A resource adapter is required to manage the auto-commit mode as follows:
A transactional resource adapter (either at XATransaction or LocalTransaction level) is required
to set the auto-commit mode (for a Connection instance participating in the transaction) to off
within a transaction. This requirement holds for both container-managed and bean-managed transaction
demarcation.
| false |
| false | technology | active | true |
Connector:SPEC:137 | 17 | 5.3 | A resource adapter is required to manage the auto-commit mode as follows:
A transactional resource adapter is required to set the auto-commit mode to on (for Connection instances) outside a transaction.
| false |
| false | technology | active | true |
Connector:SPEC:138 | 17 | 6.1 | If an Interaction implementation does not support a variant of execute method, the method is required to throw a javax.resource.NotSupportedException.
| false |
| false | technology | active | true |
Connector:SPEC:139 | 17 | 6.1 | An Interaction instance is created from a Connection and is required to maintain its asso-ciation with the Connection instance.
| false |
| false | technology | active | true |
Connector:SPEC:140 | 17 | 6.1 | The close of an Interaction instance should not close the associated Connection instance.
| false |
| false | technology | active | true |
Connector:SPEC:141 | 17 | 6.2 | It is required that the InteractionSpec interface be implemented as a JavaBean to support tools.
| false |
| false | technology | active | true |
Connector:SPEC:142 | 17 | 7.1 | A CCI implementation is required to provide an implementation class for the Connection-MetaData interface.
| false |
| false | technology | active | true |
Connector:SPEC:143 | 17 | 9.1 | A RecordFactory implementation should be capable of using the name of the desired Record and accessing meta information for the creation of the Record.
| false |
| false | technology | active | true |
Connector:SPEC:144 | 17 | 9.3 | The imple-mentations of both read and write methods for a Streamable object must call the read and write methods respectively on the super class if there is one.
| false |
| false | technology | active | true |
Connector:SPEC:145 | 17 | 10.1 | A ResultSet implementation is required to establish a type mapping between the EIS specific data types and Java types. | false |
| false | technology | active | true |
Connector:SPEC:146 | 17 | 10.3 | A CCI implementation is not required to support javax.resource.cci.ResultSetInfo in-terface.
| false |
| false | technology | active | true |
Connector:SPEC:229 | 16 | 4.1 |
For setting the security context of a Work instance, the application
server calls the setupSecurityContext method of the SecurityContext
implementation provided by the resource adapter. The following conditions are
applicable to the application server provider while calling the
setupSecurityContext method:
- The handler argument must not be null, and the CallbackHandler
implementation passed as the argument handler to setupSecurityContext
must support the following Callbacks defined in "JavaTM Authentication
Service Provider Interface for Containers" on page F-2:
- CallerPrincipalCallback
- GroupPrincipalCallback
- PasswordValidationCallback
| true |
| false | technology | active | true |
Connector:SPEC:230 | 16 | 4.1 |
For setting the security context of a Work instance, the application
server calls the setupSecurityContext method of the SecurityContext
implementation provided by the resource adapter. The following conditions are
applicable to the application server provider while calling the
setupSecurityContext method:
- The executionSubject argument must be non-null and it must not be readonly.
| true |
| false | technology | active | true |
Connector:SPEC:231 | 16 | 4.1 |
For setting the security context of a Work instance, the application
server calls the setupSecurityContext method of the SecurityContext
implementation provided by the resource adapter. The following conditions are
applicable to the application server provider while calling the
setupSecurityContext method:
- The serviceSubject argument may be null.
If it is not null, it must not be readonly.
| true |
| false | technology | active | true |
Connector:SPEC:232 | 16 | 4.1 |
On successful return of setupSecurityContext, the container must
use the "modified" executionSubject (modified as a result of handling
the various Callbacks) to establish the caller identity of the Work
instance On successful return from setupSecurityContext, the
WorkManager must ensure that the Work is set up to be executed
with the established security identity.
| true |
| false | technology | active | true |
Connector:SPEC:233 | 16 | 4.1 |
When Message Driven Beans are the MessageEndpoints,
MessageDrivenContext.getCallerPrinicipal() must return the principal
corresponding to the established security identity, and
MessageDrivenContext.isCallerInRole() must return the result of testing the
established security identity for role membership.
| true |
| false | technology | active | true |
Connector:SPEC:303 | 16 | 4.1 |
As detailed in Section 11.4 ?WorkContextProvider and WorkContext
Interface?, a Connector WorkManager must support nested Work submissions
| true |
| false | technology | active | true |
Connector:SPEC:304 | 16 | 4.1 |
The Connector WorkManager must restrict the security
context, established via the SecurityContext of a Work
instance, to that Work instance alone.
| true |
| false | technology | active | true |
Connector:SPEC:305 | 16 | 4.1 |
When a nested Work instance is submitted without a
SecurityContext, the Connector WorkManager must not inherit the
SecurityContext information of the parent Work instance. It must
establish the equivalent of
an unauthenticated caller principal for the nested Work instance.
| true |
| false | technology | active | true |
Connector:SPEC:234 | 16 | 4.2 |
A resource adapter may use the CallerPrincipalCallback to set the
container's representation of the caller principal. The CallbackHandler must
establish the argument Principal as the caller principal associated with the
invocation being processed by the container. When the argument Principal is
null, the handler will establish the container's representation of the
unauthenticated caller principal.
| true |
| false | technology | active | true |
Connector:SPEC:235 | 16 | 4.2 |
A resource adapter might use the GroupPrincipalCallback to establish the
container's representation of the corresponding group principals within the
Subject. When a null value is passed to the groups argument, the handler will
establish the container's representation of no group principals within the Subject.
Otherwise, the handler's processing of this callback is additive, yielding the
union (without duplicates) of the principals existing within the Subject, and
those created with the names occuring within the argument array. The
CallbackHandler will define the type of the created principals.
| true |
| false | technology | active | true |
Connector:SPEC:237 | 16 | 4.4 |
The application server must provide tools to set up Caller Identity
information for a Work/Message Endpoint container. This includes
support for mapping of EIS/resource principals to Caller Principals
in the application server security domain.
| false |
| false | technology | active | false |
Connector:SPEC:238 | 16 | 4.4 |
To handle Principal Mapping scenarios described above, the application
server must provide a CallbackHandler that can be configured to
perform Principal Mapping during its handling of the
CallerPrincipalCallback and GroupPrincipalCallbacks.
| true |
| false | technology | active | true |
Connector:SPEC:239 | 16 | 4.5.1 |
On return from setupSecurityContext, the container must determine
whether or not it handled the CallerPinciplaCallback. If it determines
that it did not handle the Callback, the container must transform
the contents of the executionSubject and of any related authentication
state to be equivalent to that which would have resulted had it
handled the Callback on behalf of the resource adapter.
| true |
| false | technology | active | true |
Connector:SPEC:240 | 16 | 4.1 |
The Connector WorkManager must suspend any existing (if
any) security context on a thread performing the containing
Work, and use the new security context established by the
SecurityContext of the nested Work. Once the nested Work
instance completes, the Connector WorkManager must then restore
the security context of the containing Work instance in the thread.
| true |
| false | technology | active | true |
Connector:SPEC:241 | 16 | 4.7 |
The application server must support the SecurityContext
interface. It must also satisfy all the requirements stated in
Section 16.4.1 "Establishing the Security Context"
| true |
| false | technology | active | true |
Connector:SPEC:242 | 16 | 4.7 |
The application server must support resource adapters that employ
Case 1 or 2 style integration mode. Cases 1 and 2 are detailed
in Section 16.4.3 "Case 1: Resource Adapter Provides an Identity
in the Container Security Domain" and Section 16.4.4 "Case 2:
Identity Translated between Security Domains" respectively.
| true |
| false | technology | active | false |
Connector:SPEC:243 | 16 | 4.7 |
The application server must provide configuration tools to establish
Caller Identity information for a Message Endpoint or Work instance
as stated in Section Section 16.4.4 "Case 2: Identity Translated
between Security Domains" The application server must support the
simplifications detailed in Section 16.4.5 "Establising a Principal
as the Caller Identity"
| true |
| false | technology | active | false |
Connector:SPEC:244 | 16 | 4.7 |
The application server must support the security role assignments
relevant to the MessageEndpoint implementation as stated in Section
16.4.6 "Security Role Assignment"
| true |
| false | technology | active | false |
Connector:SPEC:266 | 18 | 3.1 |
If metadata-complete is set to "true", the deployment tool of the application
server must ignore any annotations that specify deployment information, which
might be present in the class files of the application.t
| true |
| false | technology | active | true |
Connector:SPEC:267 | 18 | 3.1 |
If metadata-complete is not specified or is set to "false", the
deployment tool must examine the class files of the application for
annotations, as specified by this specification.
| true |
| false | technology | active | true |
Connector:SPEC:268 | 18 | 3.1 |
If the deployment descriptor is not included or is included but not
marked metadata-complete, the deployment tool will process annotations.
| true |
| false | technology | active | true |
Connector:SPEC:269 | 18 | 3.1 |
Application servers must assume that metadata-complete is true for resource
adapter modules with deployment descriptor version lower than 1.6.
| true |
| false | technology | active | true |
Connector:SPEC:270 | 18 | 3.2 |
When metadata-complete is specified as false or if the metadata-complete
attribute is unspecified in the deployment descriptor, the deployment tool must
examine the classes of the resource adapter for annotations.
| true |
| false | technology | active | false |
Connector:SPEC:271 | 18 | 3.2 |
The information provided by the annotations must be merged with the deployment
descriptor packaged along with the resource adapter module.
| true |
| false | technology | active | true |
Connector:SPEC:272 | 18 | 3.2 |
While merging the information present in the annotations and the deployment
descriptor, the application server must satisfy the following requirements:
- If a deployment descriptor element and one or more annotations specify
information for the same unique identity (as specified by the XML schema), the
information provided in the deployment descriptor overrides the value specified
in the annotation.
| true |
| false | technology | active | true |
Connector:SPEC:273 | 18 | 3.2 |
While merging the information present in the annotations and the deployment
descriptor, the application server must satisfy the following requirements:
- If there is no match between the identity of the annotations and the deployment
descriptor, and as long as the XML schema allow the combination of these
identities, the information provided in the deployment descriptor must be
considered in addition to the annotations.
| true |
| false | technology | active | true |
Connector:SPEC:311 | 18 | 3.2 |
While merging the information present in the annotations and the deployment
descriptor, the application server must satisfy the following requirements:
- It is an error, either via annotations alone or as a result of the combination of
annotation and deployment descriptor, to specify combinations of identities that
do not satisfy the uniqueness constraints in the deployment descriptor schema.
| true |
| false | technology | active | false |
Connector:SPEC:312 | 18 | 3.2 |
While merging the information present in the annotations and the deployment
descriptor, the application server must satisfy the following requirements:
- The application server must consider the following exception to the above rule.
If a resource adapter module specifies the fully qualified Java class name of the
resource adapter class in the deployment descriptor through the
resourceadapter-class element, the application server must ignore any
Connector annotations in the resource adapter module?s annotation discovery
scope. If the JavaBean class specified in the resourceadapter-class
element is annotated with the Connector annotation, the application server
must use the information in the deployment descriptor to override the values
specified in the annotation.
| true |
| false | technology | active | true |
Connector:SPEC:314 | 18 | 3.2 |
The following sections will describe the metadata annotations
that are required to be supported by the application server.
| true |
| false | technology | active | false |
Connector:SPEC:315 | 18 | 3.3 |
the application server is required to process ConfigProperty annotations placed
on the superclasses while processing the configuration properties of a JavaBean.
| true |
| false | technology | active | true |
Connector:SPEC:316 | 19 | 4.2 |
The candidate objects are implementations of ResourceAdapter, ManagedConnectionFactory,
ConnectionRequestInfo, java.security.Principal, org.ietf.jgss.GSSCredential,
GenericCredential, PasswordCredential, and Record types.
These objects must override the default equals and hashCode methods, and
provide an equality behavior based on the configuration properties and class
information. That is, any two objects can be equal only if their configuration
properties match and they have the same class implementation.
| true |
| false | technology | active | false |
Connector:SPEC:274 | 18 | 4 |
If there are more than one JavaBean annotated with the Connector
annotation, the application server must use the JavaBean class specified
in the deployment descriptor through the resourceadapter-class element.
It is an error to provide a resource adapter module with more than one
JavaBean class annotated with the Connector annotation and not
providing a deployment descriptor.
| true |
| false | technology | active | true |
Connector:SPEC:275 | 18 | 4.1 |
However, if a resource adapter needs to perform tasks that uses the facilities
provided by the application server through the ResourceAdapter interface (for
example obtain a reference to the BootstrapContext, get lifecycle callbacks, or
perform inbound message delivery), the resource adapter implementation must
provide a JavaBean that implements the ResourceAdapter interface. The resource
adapter developer may, in this case, use the Connector annotation or the
deployment descriptor (See Section 20.4.1 "Resource Adapter Provider") to specify
the resource adapter JavaBean.
| true |
| false | technology | active | false |
Connector:SPEC:313 | 18 | 4.1 |
A JavaBean that is annotated with the Connector
annotation must implement the ResourceAdapter interfaces and must satisfy the
requirements listed in Section 5.3.1 'ResourceAdapter JavaBean and Bootstrapping a
Resource Adapter Instance'.
| true |
| false | technology | active | false |
Connector:SPEC:276 | 18 | 5 |
For field based annotation, if the type element is not specified by the developer, the
application server must infer its value by looking at the field declaration itself. It is
an error if the value of the type annotation element specified by the developer in
the ConfigProperty annotation, and the type of the field is not assignment
compatible.
| true |
| false | technology | active | false |
Connector:SPEC:277 | 18 | 5 |
If the defaultValue annotation element is not specified, the
application server must use the value assigned to the field, if any, as the default
value of the configuration property.
| true |
| false | technology | active | true |
Connector:SPEC:278 | 18 | 5 |
For setter method based annotations, if the type annotation element is not specified
by the developer, the application server must infer its value by inspecting the
method declartion. The property setter methods must follow the standard JavaBeans
convention (as defined by the JavaBeans Introspector class). It is an error if the
type specified by the developer in the ConfigProperty annotation and the type of
the setter method's parameter are not assignment compatible.
| true |
| false | technology | active | true |
Connector:SPEC:279 | 18 | 5 |
The application server is required to process ConfigProperty annotations
specified in the field or setter method declaration of the following JavaBeans:
- ResourceAdapter
| true |
| false | technology | active | true |
Connector:SPEC:307 | 18 | 5 |
The application server is required to process ConfigProperty annotations
specified in the field or setter method declaration of the following JavaBeans:
- ManagedConnectionFactory
| true |
| false | technology | active | true |
Connector:SPEC:308 | 18 | 5 |
The application server is required to process ConfigProperty annotations
specified in the field or setter method declaration of the following JavaBeans:
- AdministeredObject
| true |
| false | technology | active | true |
Connector:SPEC:309 | 18 | 5 |
The application server is required to process ConfigProperty annotations
specified in the field or setter method declaration of the following JavaBeans:
- ActivationSpec
| true |
| false | technology | active | true |
Connector:SPEC:280 | 18 | 5.1 |
Configuration tools provided by the container must introspect the JavaBeans listed
in Section 18.5 "@ConfigProperty" above for Connector 1.6 resource adapters to
automatically discover the configuration properties of a JavaBean through JavaBeans
introspection.
| true |
| false | technology | active | true |
Connector:SPEC:281 | 18 | 7 |
A resource adapter capable of message delivery to message endpoints must
provide a JavaBean class that implements the javax.resource.spi.ActivationSpec
interface (see Section 5.3.3 "ActivationSpec JavaBean and Inbound Communication")
or annotate a JavaBean with the Activation annotation for each supported
endpoint message listener type.
| true |
| false | technology | active | false |
Connector:SPEC:282 | 18 | 7 |
The ActivationSpec JavaBean may implement the ResourceAdapterAssociation
interface directly to be associated with the resource adapter instance.
In such cases, the application server must associate the appropriate
ResourceAdapter instance with the ActivationSpec JavaBean prior to use as
described in Section 5.3.3 "ActivationSpec JavaBean and Inbound Communication".
| true |
| false | technology | active | true |
Connector:SPEC:283 | 18 | 8 |
This annotation element is optional and when this value is not
provided by the resource adapter provider, the application server must
use the following rules to determine the Java interfaces of the
administered object.
- The following interfaces must be excluded while determining the Java interfaces
of the administered object: java.io.Serializable and java.io.Externalizable
- If the JavaBean implements only one interface, that interface is chosen
as the Java Interface implemented by the administered object
- If the JavaBean class implements more than one Java interface, the resource
adapter provider must explicitly state the interfaces supported by the
administered object either through the adminObjectInterfaces annotation
element or through the deployment descriptor. It is an error if the resource
adapter provider does not use either of the two schemes to specify the Java types
of the interfaces supported by the administered object.o
| true |
| false | technology | active | false |
Connector:SPEC:321 | 18 | 9 |
These resource definition annotations must be supported in all
runtime environments that supports the deployment of the modules
that are allowed define these annotations. It is not required to
support the placement of these resource definitions in classes
packaged in resource adapter modules.
| true |
| false | technology | active | false |
Connector:SPEC:327 | 18 | 9 |
These resource definition annotations must only be defined in
modules that have access to the resource adapter as per the
rules defined in Section 20.2.0.4, Requirements on page 20-5.
| true |
| false | technology | active | false |
Connector:SPEC:328 | 18 | 9 |
It is not required to support the placement of these resource
definitions in classes packaged in resource adapter modules.
| true |
| false | technology | active | false |
Connector:SPEC:322 | 18 | 9.1 |
A resource adapter name that the connection factory must be created
from, must be indicated by the resourceAdapter element. The resource
adapter is required to be available at deployment time.
| true |
| false | technology | active | false |
Connector:SPEC:323 | 18 | 9.1 |
The transactionSupport annotation element specifies the level of
transaction support the connection factory needs to support. If a
transaction support specification is specified, it must be a level
of transaction support whose ordinal value in the TransactionSupport.Transaction
SupportLevel enum is equal to or lesser than the resource adapters
transaction support classification.
| true |
| false | technology | active | false |
Connector:SPEC:324 | 18 | 9.2 |
A resource adapter name that the administered object must be created
from, must be indicated by the resourceAdapter element. The resource
adapter is required to be available at deployment time.
| true |
| false | technology | active | false |
Connector:SPEC:325 | 18 | 9.3 |
The mandatory fully qualified class name of the administered objects
class must be indicated by the className element. The fully qualified
class name of the administered objects interface must be indicated
by the interfaceName element, only if the class indicated in the
className element implements more than one interface and the application
server cannot determine the unique Java interface of the administered
object according the rules defined in Section 18.8, @AdministeredObject
on page 18-15.
| true |
| false | technology | active | true |
Connector:SPEC:326 | 18 | 9.3 |
The name of the resource adapter that the administered object must be
created from must be indicated by the resourceAdapter element. The
resource adapter must be available at runtime prior to any attempt to
access the administered object.
| true |
| false | technology | active | true |
Connector:SPEC:284 | 19 | 1 |
The application server must support the deployment of a resource
adapter in EJB and Web containers.
| true |
| false | technology | active | true |
Connector:SPEC:285 | 19 | 1 |
The application server must support all the connector architecture API
requirements in EJB and Web containers.
| true |
| false | technology | active | true |
Connector:SPEC:286 | 19 | 1 |
A single resource adapter instance may be shared by both a Web
container and an EJB container.
| true |
| false | technology | active | true |
Connector:SPEC:287 | 19 | 1 |
The application server must support all versions of the resource adapter DTDs
(Document Type Definitions) and the resource adapter XML Schema Definition.
| true |
| false | technology | active | true |
Connector:SPEC:147 | 20 | 1 | A resource adapter module must be deployed either: Directly into an application server as a stand-alone unit, or,
Deployed with a J2EE application that consists of one or more J2EE modules in addition to a resource adapter module. The J2EE specification specifies requirements for the assembly and packaging of J2EE applications.
| true |
| false | technology | active | true |
Connector:SPEC:148 | 20 | 2 | A resource adapter must be packaged using the Java ARchive (JAR) format in to an RAR (ResourceAdapter ARchive).
| true |
| false | technology | active | false |
Connector:SPEC:149 | 20 | 2 | The deployment descriptor must be stored with the name META-INF/ra.xml in the RAR file.
| true |
| false | technology | active | false |
Connector:SPEC:150 | 20 | 2 | The Java interfaces, implementation and utility classes (required by the resource adapter) must be packaged as one or more JAR files as part of the resource adapter module.
| true |
| false | technology | active | false |
Connector:SPEC:151 | 20 | 2 | The deployer must ensure that all the JAR files (packaged within a resource adapter module) are loaded in the operational environment.
| true |
| false | technology | active | false |
Connector:SPEC:152 | 20 | 2 | A resource adapter module must be deployed based on the deployment requirements specified by the resource adapter provider in the deployment descriptor.
| true |
| false | technology | active | false |
Connector:SPEC:153 | 20 | 3 | When a resource adapter RAR packaged within a J2EE application EAR is deployed, the resource adapter must be made available only to the J2EE application with which it is packaged.
| true |
| false | technology | active | true |
Connector:SPEC:300 | 20 | 3 |
If an application references a resource using a deployment descriptor entry or a
corresponding annotation, and that resource is supplied by a standalone resource
adapter, that standalone resource adapter must be made available to the
application.
| true |
| false | technology | active | true |
Connector:SPEC:301 | 20 | 3 |
If an application references an extension using the Extension Mechanism
Architecture (See Section EE.8.2 "Library Support" of "JavaTM Platform,
Enterprise Edition (Java EE) Specification, version 6" on page F-1) and a jar file
within a standalone resource adapter supplies that extension, the standalone
resource adapter must be made available to the application.
| true |
| false | technology | active | true |
Connector:SPEC:302 | 20 | 3 |
If a standalone resource adapter is configured to deliver messages
to a Message Driven Bean in an application, the standalone resource
adapter must be made available to the application.
| true |
| false | technology | active | true |
Connector:SPEC:154 | 20 | 3.1 | The resource adapter provider must specify the fully qualified name of a Java class that implements the javax.resource.spi.ResourceAdapter interface.
| true |
| false | technology | active | false |
Connector:SPEC:155 | 20 | 3.1 | The resource adapter provider must specify the fully qualified name of the Java class that implements the javax.resource.spi.ManagedConnectionFactory interface.
| true |
| false | technology | active | false |
Connector:SPEC:156 | 20 | 3.1 | The resource adapter provider must specify the fully-qualified name of the Java interface and implementation class for each connection supported by the resource adapter.
| true |
| false | technology | active | false |
Connector:SPEC:157 | 20 | 3.1 | The resource adapter provider must specify all authentication mechanisms supported by the resource adapter.
| true |
| false | technology | active | false |
Connector:SPEC:158 | 20 | 3.1 | The resource adapter provider must specify one or more message listener types supported by a messaging resource adapter.
| true |
| false | technology | active | false |
Connector:SPEC:159 | 20 | 3.1 | The deployment descriptor specified by the resource adapter provider for its resource adapter must be consistent with the XML DTD specified in Section 15.6.
| true |
| false | technology | active | false |
Connector:SPEC:160 | 20 | 3.2 | The deployment tool must first read the ra.xml deployment descriptor from the resource adapter module .rar file.
| true |
| false | technology | active | false |
Connector:SPEC:292 | 20 | 5.1 |
The Java class which implements the interface
javax.resource.spi.ResourceAdapter must be a JavaBean.
| true |
| false | technology | active | false |
Connector:SPEC:293 | 20 | 5.2 |
A resource adapter must implement the ManagedConnectionFactory
interface as a JavaBean.
| true |
| false | technology | active | false |
Connector:SPEC:294 | 20 | 5.2.1 |
The ManagedConnectionFactory implementation must be a JavaBean.p
| true |
| false | technology | active | false |
Connector:SPEC:295 | 20 | 5.3 |
The ManagedConnectionFactory implementation class must provide getter and
setter methods for each of its supported properties. The supported properties must
be consistent with the specification of configurable properties specified in the
deployment descriptor.
| true |
| false | technology | active | false |
Connector:SPEC:161 | 20 | 3.2 | A deployment tool must be capable of reading the deployment descriptor from a resource adapter module.
| true |
| false | technology | active | false |
Connector:SPEC:162 | 20 | 14.1 | There must be at least one ResourceAdapter JavaBean instance per deployment.
| true |
| false | technology | active | true |
Connector:SPEC:163 | 20 | 14.2 | A resource adapter must implement the ManagedConnectionFactory interface as a Java Bean.
| true |
| false | technology | active | false |
Connector:SPEC:164 | 20 | 15.5.1 | In both managed and non-managed environments, registration of a connection factory instance in the JNDI namespace must use either the JNDI Reference or Serializable mechanism.
| true |
| false | technology | active | false |
Connector:SPEC:296 | 21 | 2 |
An application server must provide a set of security permissions
for executing a resource adapter in a managed runtime environment.
A resource adapter must be granted explicit permissions to access
system resources
| true |
| false | technology | active | false |
Connector:SPEC:297 | 21 | 3 |
A resource adapter provider must ensure that resource adapter code does not
conflict with the default security permission set. By ensuring this, a resource adapter
can be deployed and run in any application server without execution or
manageability problems.
| true |
| false | technology | active | false |
Connector:SPEC:298 | 21 | 3 |
If a resource adapter needs security permissions other than those specified in the
default set, it must describe such requirements in the XML deployment descriptor
using the security-permission element or through the SecurityPermission
annotation described in Section 18.4.4, "@SecurityPermission" on page 18-9.
| true |
| false | technology | active | false |
Connector:SPEC:299 | 21 | 3 |
A deployment descriptor-based specification of an extended permission set for a
resource adapter allows the deployer to analyze the security implications of the
extended permission set and make a deployment decision accordingly. An
application server must be capable of deploying a resource adapter with the default
permission set.
| true |
| false | technology | active | false |
Connector:SPEC:330 | 21 | 5 |
The following JavaBeans of a resource adapter archive have their
lifecycle managed by the application server (see Chapter 5, Lifecycle Management"):
-ResourceAdapter
-ManagedConnectionFactory
-ActivationSpec
-Administered Objects
These JavaBeans may be used as CDI managed beans if they are annotated
with a CDI bean-defining annotation or contained in a bean archive for
which CDI is enabled.
| true |
| false | technology | active | false |