Hi,
On 01/03/2013 07:48 AM, Sivakumar Thyagarajan wrote:
>> This work-flow is highly vendor specific, so you can't assume that all
>> will follow / support that.
>
> The fact that a RA is configured out-of-band through vendor-specific
> means is documented in the spec (5.3.7.1).
>
Yes, but the proposal will depend on a vendor specific configuration in
order for the deployment annotations defined in the specification to
actually work.
This isn't the case development annotations as they can replace / mix
with ra.xml.
If we are going to attack the deployment descriptors then we need a
common baseline, and can't depend on a vendor specific "baseline".
Since we all have been working with 5.3.7.1 up till now every vendor
does it differently. We have to take into consideration too; something
that works for one party may not for another. And vice-versa.
>> The @ConfigProperty's for the resource adapter are done using the vendor
>> specific tools.
>
> .. to be clear, the property values for Configuration properties of a
> RAR (specified through @ConfigProperty) is specified as part of RA
> configuration during RA deployment. These properties could have default
> values, and in that case, a deployer may not even need to override them
> if the defaults works for them.
>
Correct, but they could be @NotNull, and hence require a vendor specific
configuration.
>> The @ConfigProperty's for the managed connection factories and admin
>> objects are done with the new deployment annotations.
>
> @ConfigProperty in a MCF or AdminObject again declares a configuration
> property. The values for these properties are provided for these through
> the new resource defintion annotations. Again a deployer can choose to
> override this using vendor-specific schemes (a vendor DD, tools etc).
>
As above.
Best regards,
Jesper