Hi Jesper
On Saturday 12 January 2013 01:01 AM, Jesper Pedersen wrote:
> Hi,
>
> A follow-up on our discussion about deployment annotations.
>
> The current suggestion includes two annotations for deployment of a
> connection factory and an admin object.
>
> They contain a field 'resource-adapter-name' which references the resource
> adapter deployment they belong to.
>
> 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.
> 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?
> 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.
Thanks
--Siva.
> The annotation deployment must be able to tie against a precise
> ResourceAdapter instance in order to fulfill the
> ResourceAdapterAssociation requirements.
>
> This can solved by having a deployment model for an entire resource
> adapter deployment which is scoped, like
>
> @ResourceAdapterDeployment
> (
> resource-adapter="eis.rar"
>
> @ResourceAdapterConfiguration(
> config-properties=
> {{"raValue", "value1"}}
> )
>
> @ConnectionFactoryDefinitions(
> @ConnectionFactoryDefinition(
>
> )
>
> @ConnectionFactoryDefinition(
>
> )
> )
>
> @AdminObjectDefinitions(
> @AdminObjectDefinition(
>
> )
>
> @AdminObjectDefinition(
>
> )
> )
> )
>
> with additional fields, of course, for a agreed upon baseline of
> functionality.
>
> Since we havn't covered standardized deployment in any of the previous
> specifications I think we should push this issue to the next version of
> the specification, so we aren't forced to work against a tight deadline.
> We need to get this right for it to be used.
>
> Users will continue to be able to use the
>
> public class MyServlet ...
> {
> @Resource(mappedName = "java:/MyCF")
> private MyConnectionFactory myCF;
>
> ...
> }
>
> way of obtaining a connection factory or admin object, using vendor
> specific deployment tools.
>
> Best regards,
> Jesper