If password alias support will be mandatory for AS, should confidential properties support also be marked as mandatory for AS? IIUC, confidential properties is a optional feature to both adapters and AS in Connector 1.6.
Also, the proposal for section 5.3.7.6 uses 'is responsible for', does it mean 'must'? may be reworded to make it clearer.
A minor suggestion: add 'AdministeredObject' to the 'Impact' section:
*Impact*
With this change, while a value for a configuration property for a
JavaBean such as Resource Adapter, MCF, AdministeredObject or ActivationSpec is specified
by a user
Thanks
Wilson
> -----Original Message-----
> From: Sivakumar Thyagarajan
> Sent: Wednesday, December 05, 2012 11:49 PM
> To: jsr322-experts_at_connector-spec.java.net
> Cc: Jesper Pedersen
> Subject: [jsr322-experts] Re: Supporting password aliases in Confidential Properties and the Password Property
>
> Hi Jesper
>
> On Tuesday 04 December 2012 07:36 PM, Jesper Pedersen wrote:
> > Hi,
> >
> > On 12/03/2012 10:53 PM, Sivakumar Thyagarajan wrote:
> >> Could we require application servers to support the specification
> >> (and
> >> resolution) of Password aliases in all Configuration Properties of a
> >> JavaBean that are marked as confidential, and the standard "Password"
> >> Configuration Property?
> >>
> >> *Impact*
> >> With this change, while a value for a configuration property for a
> >> JavaBean such as Resource Adapter, MCF or ActivationSpec is specified
> >> by a user, the user could use a password alias. The application
> >> server is required to resolve this alias and pass the resolved
> >> plain-text password to the resource adapter.
> >>
> >> *Spec Impact*
> >> Section 5.3.7.6: Add the following lines: "A Password alias may be
> >> used while configuring confidential properties. The application
> >> server is responsible for resolving the alias and passing the clear
> >> text password to the JavaBean. For more details on the Password Alias
> >> feature and its format, see Section EE.3.7 "Password Aliasing and
> >> Management" of the Java EE 7 platform specification."
> >>
> >> Section 20.5.4: Add the following lines: "The application server must
> >> support the specification of password aliases in the Password
> >> standard Property. For more details on the Password Alias feature and
> >> its format, see Section EE.3.7 "Password Aliasing and Management" of
> >> the Java EE 7 platform specification"
> >>
> >
> > I agree with this change.
> >
> > However, you can't make it a mandatory requirement, since existing
> > certified implementations doesn't support this feature.
>
> A spec usually goes through two types of changes through the MR process:
> - Errata: These are small changes to a spec that don't change the meaning of the spec(typos, fixing obvious
> inconsistencies in the spec, clarifications). In most cases, an errata should not require a change to the
> implementation or the TCK. This does not require a new spec version.
> In this case we can't bring in new features that existing certified implementations cannot support.
> - API Changes: These are changes that change the meaning of the spec, adds features etc. This could be API
> signature changes (adding a class, method), behavior changes, requirement changes. The requirement is that such
> changes are backward compatible with the previous version of the specification. These changes results in new
> assertions, a new spec version (Connectors 1.7 in our case), new TCK version etc. A EE7 implementation must
> support this new Connector spec version (1.7) and hence there is no issue in adding features (as long as the
> added features are not backward compatible with the earlier version of the spec)
>
> In this MR that we are aiming for EE7, we would add new APIs (to support JMS/EJB changes, for the new resource
> definition annotations), and so we fall in the second category. So, I would like to suggest that this can remain
> as a "must".
>
> Thanks
> --Siva.
>
> > So change "must" to "may".
> >
> > File an issue for JCA.next to make it mandatory and adding a TCK test
> > for the functionality. In JCA.next the standalone environment
> > definition would need an update to make this feature optional ("may"),
> > since it isn't tied to the EE spec.
> >
> > Best regards,
> > Jesper
> >
>