Hi Wilson
On Thursday 06 December 2012 12:35 PM, Wilson Tian wrote:
> 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.
I don't think requiring support for resolving password aliases
in a confidential property requires the application server
to support confidential property. Could we say that if an
application server supports confidential properties, it must
support resolving password aliases.
In Connector 1.6, we did not get enough interest in
mandating this, as the real visible semantic of a
confidential property is how it is treated in tools/UI etc,
which wasn't specified clearly anyway.
Does anyone think that we must standardize the support for
confidential properties?
> Also, the proposal for section 5.3.7.6 uses 'is responsible for', does
> it mean 'must'? may be reworded to make it clearer.
Agreed, thanks.
> 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>
Good catch. Sure, I will include this.
Thanks
--Siva.
> 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
>>>
>>