users@connector-spec.java.net

[connector-spec-users] [jsr322-experts] Re: Usage of required-config-property and @NotNull

From: Sivakumar Thyagarajan <sivakumar.thyagarajan_at_oracle.com>
Date: Tue, 12 Mar 2013 22:31:56 +0530

Hi Fred

On Tuesday 12 March 2013 06:46 PM, frowe_at_us.ibm.com wrote:
> Prior to JCA 1.6, an RA developer could use the
> <required-config-property> element in ra.xml to indicate that a config
> property of an ActivationSpec was required. The use of this element
> type within other RA entities was not discussed in the spec and
> accordingly in the XSD, the only place in which the
> required-config-propertyType was used was within the activationspecType
> definition. Its use was not allowed for any of the other objects like
> RA, AO, CF, etc, instead they all use <config-propertyType>. With the
> addition of BeanValidation capabilities to JCA 1.6, we deprecated the
> <required-config-property> deployment descriptor element and
> recommended using @NotNull instead. However, in doing so, there was no
> limitation on the JavaBean types which could be decorated with this
> annotation which corresponded to the limitation of its use on an
> ActSpec as specified in the XSD. This leads to a situation where in
> JCA 1.6, one can create an annotated RA for which an equivalent ra.xml
> can't legally be constructed, for example, by creating a java bean
> class annotated with @AdministeredObject and then annotating one of its
> public fields with @NotNull. The equivalent deployment descriptor
> would have a <required-config-property> element as a child of a
> <adminobject> object which should fail schema validation. I believe a
> clarification should be made to the 1.7 MR to correct this issue.

The support for Bean Validation constraint annotations for JavaBeans
listed in 5.3.7.5 is not just limited to @NotNull. For instance a user
could a range specification annotation such as @Min @Max etc for which
there are no equivalents in the ra.xml.

The standard mechanism to declare or override specified constraints in a
JavaBean through DD is through the use of the standard bean validation
configuration descriptor, META-INF/validation.xml (Chapter 7 of the Bean
Validation 1.0 spec).

Could that be considered for the scenario you describe above?

Thanks
--Siva.