users@connector-spec.java.net

[connector-spec-users] [jsr322-experts] Re: Please review the first draft of the Connectors 1.7 specification

From: Sivakumar Thyagarajan <sivakumar.thyagarajan_at_oracle.com>
Date: Wed, 06 Feb 2013 18:40:30 +0530

Hi Fred

On Wednesday 06 February 2013 06:15 PM, Frederick W Rowe wrote:
> Hello Siva,
>
> Maybe it's the use of the term "available". What does that mean? That
> the RAR is present in the app ear/war/etc or is deployed as a standalone
> RAR? I'm ok with that interpretation of "available", but not meaning
> "running".
> You mentioned alignment with @DataSourceDefinition, can you be more
> specific?

The DataSourceDefinition annotation (Section 2.13 defined in the Common
Annotations spec [1]) says: "The driver class is not required to be
available at deployment but must be available at runtime prior to any
attempt to access the DataSource."

To be clear and precise, I can change the text in our section 18.9.1 to
say something similar:
"The resource adapter must be available at runtime prior to any attempt to
access the ConnectionFactory." (and 'Administered Object' in 18.9.2)

Would this clarify the intent?

> On the issue of CDI, I'll look for your clarification today...

The latest draft that I circulated earlier this week [2], has some updated
verbiage in 21.5. Does this work for you?

Thanks
--Siva.
[1] http://jcp.org/en/jsr/detail?id=250

> Regards,
>
> Fred Rowe
>
> WebSphere Architect
> Senior Software Engineer
> IBM Software Group
>
>
>
>
> Sivakumar Thyagarajan <sivakumar.thyagarajan_at_oracle.com>
> 02/01/2013 12:45 PM
>
> To
> jsr322-experts_at_connector-spec.java.net
> cc
> Frederick W Rowe/Raleigh/IBM_at_IBMUS
> Subject
> Re: [jsr322-experts] Re: Please review the first draft of the Connectors
> 1.7 specification
>
>
>
>
>
>
> Hi Fred
>
> Thanks for all your detailed comments. I will address all of them.
>
> Response to two questions that you had in your list below.
>
>>> In section 18.9.1 @ConnectionFactoryDefinition, what is the rationale
> for
>>> the requirement (vs. a suggestion) of
>>> "The resource adapter is required to be available at deployment time."
>>> Until the app is actually started, why must the RA be available? We
>>> should allow for the latest possible lazy initialization.
>
> This requriement was made, so as to align with the DataSourceDefinition.
>
> Usually processing of resource definition annotations happen during
> application deployment, so that these resources could be created during
> deployment and hence made available during runtime. Since the creation of
> the Connector resources require a functioning resource adapter, I added
> that line.
>
> Anyway for the embedded connector usecase, the embedded RAR is available
> at deployment time. It is only for standalone RARs, containers may want to
>
> do some lazy initialization, but even in those cases, if the container
> creates resources during deployment time, the referred standalone RAR must
>
> be available, right?
>
> Would rewording that line to say "The resource adapter is required to be
> available at the time the resources are created by the application
> server", be good? I found this definition to be a bit too vague for the
> reader.
>
>>> Does section 21.5 Dependency Injection now require an app server to
>>> support CDI for a RAR bean archive?
>
> Support CDI for a RAR archive may mean many things. In this release:
> - Supporting RAR as a bean archive: Yes, as per the CDI spec
> - Support CDI injection in managed JavaBeans (like ResourceAdapter class):
>
> AS may or may not support this, and the injected Beans (if they are
> managed JavaBeans) may or may not be the instance the AS is managing.
> - Support injection in managed JavaBeans (like ResourceAdapter class) in
> other component classes like Servlet: AS may or may not support this.
>
> I am working on coming up with a verbiage that makes these scenarios
> clearer (as suggested in our EG call this week), and will circulate is as
> part of the MR candidate draft (that I should send out to the EG for
> review by tomorrow).
>
> Thanks
> --Siva.
>
>
>
> On Thursday 31 January 2013 05:55 PM, Frederick W Rowe wrote:
>> Comments on first draft of JCA 1.7 spec:
>>
>> In section 5.3.7.6 Configuration Property Attributes, I thought password
>> aliases had been removed from EE7 spec? If so, an update is needed to
>> this section to remove the references.
>>
>> Typo in paragraph of section 13.3 Message Inflow Model "where the
> failure
>> to create an endpoint is temproary,"
>>
>> New paragraph added to section 13.3 Message Inflow Model for unique name
>> has a typo (two periods):
>> "The MessageEndpointFactory also provides the unique name for the
> message
>> endpoint deployment that it represents. . If the message endpoint has
> been
>> deployed"
>>
>> Consider rewording first paragraph of section 18.9 Resource Definition
>> Annotations to avoid double negative "more minimal"
>> Instead of "Resource definition annotations allow an application to be
>> deployed into a Java EE
>> environment with more minimal administrative configuration." consider
>> "Resource definition annotations allow an application to be deployed
> into
>> a Java EE
>> environment with less administrative configuration."
>>
>> Consider rewording third paragraph of section 18.9 Resource Definition
>> Annotations to avoid ending sentence in preposition and mismatch of
>> subject and verb number:
>> Instead of "These resource definition annotations refer to a resource
>> adapter name from which
>> the resources needs to be created from." consider "These resource
>> definition annotations refer to a resource adapter by name, from which
>> the resources need to be created."
>>
>> Why does section 18.9 Resource Definition Annotations use the munged
> term
>> "resourceadapterName"? Instead of
>> "When a resource adapter RAR packaged within a Java EE application EAR
>> needs to be referenced, the resourceadapterName may prefix the name with
> a
>> “#” character to"
>> consider "When a resource adapter RAR packaged within a Java EE
>> application EAR needs to be referenced, the resource adapter name may be
>> prefixed with a “#” character to"
>>
>> We discussed rewording the last paragraph of section 18.9 Resource
>> Definition Annotations
>> Instead of:
>> "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."
>> consider
>> "These resource definition annotations must be supported in all runtime
>> environments that support the deployment of a module which may define
>> these annotations. It is not required to support the placement of these
>> resource
>> definitions in classes packaged in resource adapter modules."
>>
>> Correct repeated words in second paragraph of section 18.9.1
>> @ConnectionFactoryDefinition
>> "Section EE.5.2.6 of the Java EE Platform Specification describes how
>> environment
>> entries created by these annotations annotations..."
>>
>> In section 18.9.1 @ConnectionFactoryDefinition, correct formatting
> problem
>> in
>> "The connection factory will be registered in JNDI under the name
>> specified in the
>> mandatory name annotation element." (mandatory and annotation appear in
>> Courier font instead of regular Palatino).
>>
>> In section 18.9.1 @ConnectionFactoryDefinition, instead of
>> "A resource adapter name that the connection factory must be created
> from,
>> must be
>> indicated by the resourceAdapter element." consider "The resourceAdapter
>> element specifies the name of a resource adapter from which the
> connection
>> factory must be created."
>>
>> In section 18.9.1 @ConnectionFactoryDefinition, what is the rationale
> for
>> the requirement (vs. a suggestion) of
>> "The resource adapter is required to be available at deployment time."
>> Until the app is actually started, why must the RA be available? We
>> should allow for the latest possible lazy initialization.
>>
>> In section 18.9.1 @ConnectionFactoryDefinition instead of "Additional
>> properties that are required by the ManagedConnectionFactory, that is
>> associated
>> with the connection factory being defined, are specified through the
>> properties element." consider
>> "Additional properties required by the ManagedConnectionFactory
> associated
>> with the connection factory being defined, are specified through the
>> properties element."
>>
>> In section 18.9.2 @AdministeredObjectDefinition correct copy-n-paste
> error
>> in
>> "See Section EE.5.19.8 of the Java EE Platform Specification for more
>> details on the connection factory resource definition annotation."
>> to state "See Section EE.5.19.8 of the Java EE Platform Specification
> for
>> more details on the administered object resource definition annotation."
>> Also, verify that the section reference is correct.
>>
>> Correct repeated words in second paragraph of section 18.9.2
>> @AdministeredObjectDefinition
>> "Section EE.5.2.6 of the Java EE Platform Specification describes how
>> environment
>> entries created by these annotations annotations..."
>>
>> In section 18.9.2 @AdministeredObjectDefinition
>> correct "CODE EXAMPLE 18-15 AdministeredObject Annotation" to state
> "CODE
>> EXAMPLE 18-15 AdministeredObjectDefinition Annotation"
>>
>> In section 18.9.2 @AdministeredObjectDefinition, instead of
>> "A resource adapter name that the administered object must be created
>> from, must be
>> indicated by the resourceAdapter element." consider "The resourceAdapter
>> element specifies the name of a resource adapter from which the
>> administered object must be created."
>>
>> In section 18.9.2 @AdministeredObjectDefinition instead of "Additional
>> properties that are required to be configured in the
>> AdministeredObject, are specified through the properties element."
>> consider
>> "Additional properties required by the AdministeredObject associated
>> with the administered object being defined, are specified through the
>> properties
>> element."
>>
>> In section 18.9.2.1 Example, correct "CODE EXAMPLE 18-17
>> ConnectorResourceDefinition Annotation Usage Example" to state "CODE
>> EXAMPLE 18-17 AdministeredObjectDefinition Annotation Usage Example"
>>
>> In section 20.5.4 Standard Properties, I believe that the reference to
>> password aliases needs to be removed since it was deferred to EE8?
>> "The application server must support the specification of password
> aliases
>> in the Password standard Property. For more details on password aliases
>> and its format,
>> see Section EE.3.7 "Password Aliasing and Management" of the “Java
>> Platform, Enterprise Edition (Java EE) Specification, version 7” on page
>> E-1."
>>
>> Does section 21.5 Dependency Injection now require an app server to
>> support CDI for a RAR bean archive?
>>
>> Second bullet of Change History for 1.7 should point to 5.3.7.6
>> Configuration Property Attributes on page 5-17 instead of ActSpec
>>
>>
>> Regards,
>>
>> Fred Rowe
>>
>> WebSphere Architect
>> Senior Software Engineer
>> IBM Software Group
>> frowe_at_us.ibm.com
>>
>
>
>