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
>