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 |