Hi,
On 01/21/2013 08:38 AM, Sivakumar Thyagarajan wrote:
>> However, the actual deployment of the ResourceAdapter instance is done as
>> part of the vendor specific activation giving:
>
> The deployment of the RA is a 'module' deployment and there exists
> JSR-88 like APIs to deploy a RAR, and this IMHO should not be linked
> with resource definition annotations.
>
What do you mean by this ?
>> Configuration Annotations
>>
>> (CF) CF
>> | |
>> RA-------- resource-adapter-name ------
>> | |
>> (AO) AO
>>
>> where 'Configuration' is the vendor specific part, and 'Annotations' is
>> the annotations defined in the specification.
>
> In the left hand side of the figure, should we read the (CF) and (AO)
> are as entities created by the container automatically based on CF and
> AO resource definition annotations placed in the application?
>
No, the 'Configuration' side of the diagram is the deployment /
activation of the resource adapter instance with a given
'resource-adapter-name'. This deployment has at least a ResourceAdapter
instance. However, there may be ConnectionFactory's and AdminObject's too.
The 'Annotations' side of the diagram is the application where the
resource adapter deployment annotations are located.
>> The resource-adapter-name field must clearly identify which deployment
>> they belong to. The identifier is vendor specific though and may not even
>> be available depending on the vendors deployment model.
>
> The EE platform requirements in Section EE.8.1.1 (in para starting with
> 'All Java EE modules have a name.') indicate that all deployed modules
> must have a 'name' and it is defaulted to the specified name of the
> moduls. There are cases where (in the case of conflicts only) the
> deployment tool can, in a vendor-specific manner, devise a name EE.8.1.1.
>
> So, the point about no names being available is invalid in an EE
> application server. We have talked about standalone connector containers
> in another thread and that is a whole new ball game.
>
>> This results in that vendor specific overrides are required, since a
>> standard format of the field can't be specified. This limits the
>> usability
>> of the annotations.
>
> The name is only vendor-specific if it's not unique. If the resource
> adapter is bundled with the application, the application assembler can
> ensure that module names are unique.
>
> So though the resource-adapter-name may be vendor-specific in some
> cases, in most cases (arguably 99% of the time) the name is known ahead
> of time.
>
> It is well known for embedded RARs (when the application assembler
> ensures there are no name conflicts in the EAR), and for standalone RARs
> where the target RAR is known. Since this name is known ahead of time,
> such vendor-specific overrides should be few.
>
> Due to these reasons, I don't understand why we would need to define the
> scoped deployment model you outline below.
I think I have explained why this won't work in real life, making the
annotations useless.
Counting on 'everything is default' is going to break the first time a
simple change is made somewhere.
Having a model where everything is explicit defined is the best way to
handle this scenario. Or not doing it at all.
Best regards,
Jesper