## Jakarta Connectors - 2.0
Specification Assertion Detail

Totals | Total | Active | Deprecated | Removed
# of Assertions | 287 | 287 | 0 | 0
# of Required Assertions | 241 | 241 | 0 | 0
# of Optional Assertions | 46 | 46 | 0 | 0

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 jakarta.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: jakarta.resource.spi.ManagedConnectionFactory jakarta.resource.spi.ManagedConnection jakarta.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): jakarta.resource.spi.ConnectionEvent jakarta.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 jakarta.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: jakarta.resource.spi.ManagedConnectionFactory jakarta.resource.spi.ManagedConnection jakarta.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 jakarta.resource.spi.ConnectionManager interface. | true |  | false | technology | active | true
Connector:SPEC:32 | 6 | 10.2 | An application server is required to implement the jakarta.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 jakarta.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 jakarta.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 'jakarta.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 jakarta.ejb.EJBException (which is a java.lang.RuntimeException) and throw the jakarta.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 jakarta.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 jakarta.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 jakarta.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 jakarta.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 jakarta.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 jakarta.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 jakarta.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 jakarta.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