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?
On the issue of CDI, I'll look for your clarification today...
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
>