javaee / connector-spec Goto Github PK

WorkContextProvider extends Serializable which means that the implementing Work must then be Serializable when there was no prior need. I believe that WorkContextProvider would only need to be Serializable if the Work is actually a DistributableWork, in which case the implementation is already forced to be Serializable.

Requiring WorkContextProvider to be Serializable creates extra work for developers when doing otherwise simple things like providing HintsContext.LONGRUNNING_HINT.

(Apologies if I have this all wrong but I couldn't find a public forum to discuss this in).

Thanks to Jesper for reporting this.

1. In section D.5.1. bullet 4)

create-ManagedConnection => createManagedConnection

2. MessageEndpointFactory::isDeliveryTransacted(Method method)

getBeanClass => getEndpointClass

http://docs.oracle.com/javaee/7/api/javax/resource/spi/endpoint/MessageEndpointFactory.html#isDeliveryTransacted(java.lang.reflect.Method

This is a request for two new methods on javax.resource.spi.endpoint.MessageEndpointFactory:

String getEndpointUniqueName()

Returns a unique name for this message endpoint. If the application has been deployed into a clustered application server then this method must return the same name for the same endpoint in each application server instance. Otherwise, a different name must be returned for every endpoint in every application in every application server instance.

The name must consist of Java letters or digits (as defined in the Java Language Specification) or the ASCII underscore (_ or \u005f).

The resource adapter may use this value as a valid JMS subscription name, either on its own or in combination with the value returned by the getInstanceName method. This value may be used on its own if the subscription name needs to be the same for the same endpoint in each application server instance within a cluster but otherwise unique. This value may be used in combination with the value returned by the getInstanceName method if the subscription name needs to be unique to this endpoint.

Since a durable subscription can be used to store messages indefinitely it is recommended that this name remains unchanged even if the application server is restarted or reconfigured, or if the application is redeployed.

Since a subscription name may be visible to the user or administrator it is recommended that this name is at least partly human-readable.

The combination of this value and the value returned by the getInstanceName method should be no longer than 128 characters.

String getInstanceName()

Returns the name of the application server instance in which this method is being executed. If the application has been deployed into a clustered application server then this name must be different for every instance within the cluster. Otherwise this name may have any value, including the empty string.

The name should be human-readable. It is recommended that this name remains unchanged even if the application server instance is restarted or reconfigured.

The name must consist of Java letters or digits (as defined in the Java Language Specification) or the ASCII underscore (_ or \u005f).

The resource adapter may use this value in combination with the value returned by the getInstanceName method as a valid JMS subscription name which is unique to this endpoint.

Since a subscription name may be visible to the user or administrator it is recommended that this name is at least partly human-readable.

The combination of this value and the value returned by the getEndpointUniqueName method should be no longer than 128 characters.

As part of the EoD related changes in Connector 1.6, the spec had made it optional(in
Section 18.7) for an ActivationSpec JavaBean to implement the
javax.resource.spi.ActivationSpec interface. However this prevents such a JavaBean
to be provided by the application server during endpoint
activation/deactivation/transaction recovery as the ResourceAdapter interface
requires the activation spec to be an instance of the ActivationSpec interface.

ResourceAdapter.endpointActivation(MessageEndpointFactory endpointFactory, ActivationSpec spec) [1]

To fix this, we need to remove the optional phrase in 18.7 and make it mandatory for
a JavaBean that is annotated with the @activation annotation to implement
the ActivationSpec interface.

[1] http://java.sun.com/javaee/6/docs/api/javax/resource/spi/ResourceAdapter.html#endpointActivation(javax.resource.spi.endpoint.MessageEndpointFactory,%20javax.resource.spi.ActivationSpec

EE7 introduces the ability to reference a moniker or token
instead of an actual password in configuration, annotations
(Password Aliasing feature) and goes on to describe annotations
and deployment descriptors that are required to support
aliasing.

The proposal is to require application servers to support the
specification (and resolution) of Password aliases in all
Configuration Properties of a JavaBean that are marked
as confidential (Section 5.3.7.6 of the Connectors 1.6 specification),
and the standard "Password" Configuration Property.

When performing recovery and processing inbound messages, an XAResource is obtained from the resource adapter by invoking the method getXAResources(ActivationSpec[] specs). For those returned XAResource objects, what is the expected means to destroy them since there is no API method to do so?

EXAMPLE 18-12 ConnectionFactoryDefinition Annotation in section 18.9.1 @ConnectionFactoryDefinition lists a field name "String className();", however, the corresponding api jar class has no such field, only "String interfaceName();"
Given that implementations are already using the api jar, I propose that the spec be updated to conform with the api jar.

EJB_SPEC-127 proposes that a standard way be defined to associate a JMS MDB (or any other type of MDB) with a resource adapter, using either ejb-jar.xml or the MessageDriven annotation.

This is a request that the impact of that change on the connector spec be considered, and the connector spec updated to support that change if necessary.

With the JMS specification defining the standard configuration
elements for all JMS RAs, the non-normative Appendix B is not relevant
in our specification.

Spec impact:
We could remove Appendix B, and instead provide a pointer to the JMS
spec (Chapter 12) for more information on JMS RA configuration.

Define requirements for the support of a connector connection factory resource definition through annotations (Section EE.5.19 of the Java EE 7 Platform Spec, EDR-2) and deployment-descriptor in application components.

Today the system administrator has to make Connection Factory resources that are required for an application. It would make it easier for a developer to get started if we allow an application to specify the definition and configuration of resources that it requires in its operational
environment.

The EE7 specification has already started work on this by defining two connector related resources

• Connector or Custom Resource Definition and
• Connector Administered Object Definition.

The attached proposal discusses issues with the too-generic connector resource definition and suggests that we remove the current section "EE.5.19.7 Connector or Custom
Resource Definition", and instead specify requirements for the support of a connector connection
factory resource definition.

This is a request for a new feature which would allow the delivery of messages to an endpoint to be paused and restarted without the need to completely deactivate the endpoint.

This feature would allow application servers to offer a "pause/resume message delivery" feature to users, which is something that GlassFish customers have requested.

Section 5.3.7.2 Resource Adapter Deployment states that config
properties of the RA may be inherited and used to configure an AO:
"The ResourceAdapter instance property values may be stored separately
and
reused later while configuring ManagedConnectionFactory,
ActivationSpec, or
administered object instances."

The ConnectionFactory and ActivationSpec JavaBean sections confirm that
RA props may be inherited by the JavaBeans, for example in Section
5.3.7.3 ManagedConnectionFactory JavaBean Instance Configuration:
"Apply the ResourceAdapter instance property values, that were stored
earlier, on the ManagedConnectionFactory instance. Note, that the
ManagedConnectionFactory JavaBean may have none, some or all of the
properties of the ResourceAdapter JavaBean."
but the Admin Object JavaBean section has no such bullet:
"13.4.2.4 Configuring Administered Objects
■ Create an administered object JavaBean instance. This will initialize
the instance with the defaults specified through the JavaBean mechanism.
■ Apply the administered object class configuration properties
specified in the
resource adapter deployment descriptor, on the administered object
instance. This may override some of the default values specified by way of the
JavaBean mechanism.
■ The application server is required to merge values specified by way
of annotations and deployment descriptors as specified in Section 18.3,
"Deployment Descriptors and Annotations" on page 18-2, before applying
the administered object class configuration properties.
■ The deployer may further override the values of the administered
object before
deployment."

I believe the intent was that RA props are inherited by AO's and the
solution is to add the bullet stating this from either the
ConnectionFactory ActivationSpec config details section.

The Connector 1.6 (and the current 1.7) javadoc for SecurityContext ( http://docs.oracle.com/javaee/6/api/index.html?javax/resource/spi/work/SecurityContext.html ) has the following erroneous non-null constraint for serviceSubject.

In the description of setupSecurityContext [1], we have the following erroneous line:
"The serviceSubject argument must be non-null and it must not be read-only."

In the spec, and in the same method's 'serviceSubject' parameter javadoc, we talk about serviceSubject being nullable. The correct statement must be
"The serviceSubject argument may be null, and when not null it must not be read-only."

[1] [http://docs.oracle.com/javaee/6/api/javax/resource/spi/work/SecurityContext.html#setupSecurityContext(javax.security.auth.callback.CallbackHandler](http://docs.oracle.com/javaee/6/api/javax/resource/spi/work/SecurityContext.html#setupSecurityContext(javax.security.auth.callback.CallbackHandler), javax.security.auth.Subject, javax.security.auth.Subject)

JMS 2.0 and MDB 3.2 introduces two new standard activation properties for JMS MDBs, destinationLookup and connectionFactoryLookup. These are used to specify the look-up names of the javax.jms.Destination and javax.jms.ConnectionFactory objects used by the MDB. In the case where a application server uses a resource adapter to implement a JMS MDB, this means that the endpointActivation call needs to lookup these resources by doing

InitialContext ic = new InitialContext();
Destination d = (Destination) ic.lookup(destinationLookup);

However this is only possible if the connector spec can guarantee that a call to endpointActivation will have full access to all possible application server namespaces, including java:comp. Could the spec be clarified to confirm that this is possible?

This is required for JMS_SPEC-54 and JMS_SPEC-55.

The current description of the flow isn't very clear. It should be corrected and a sequence diagram should be added.

The current JavaDoc explains the feature better.