Hi,
On 12/20/2012 01:09 PM, Sivakumar Thyagarajan wrote:
>> One or more, yes.
>
> Ok. The deployment instance of a resource adapter, is a result of a
> deployment of a deployable unit (either a standalone RAR or an EAR for
> embedded RARs), and these are usually done through application
> server-specific tools.
>
> So far, we have been discussing the ability to define annotations for
> resource definition (for resources such as Connector ConnectionFactory
> and Administered Objects that are created from a deployed instance of a
> resource adapter).
>
> The reference to the deployed instance is through the
> resourceAdapterName. So, the scoping you discuss below is done through
> that resourceAdapterName.
>
> The exact mechanism of how the 'resourceAdapterName' came into being
> (the actual deployment, configuration of the resource adapter) is all
> out-of-band. There exists portable ways by which configuration of the
> resource adapter can be handled during deployment (for instance, using
> the vendor-specific DD to override resource adapter configuration using
> JSR-88 deployment plan).
>
Well, you are assuming that the user deploys and activates a resource
adapter configuration, and then this configuration is referenced by the
annotations.
A couple of points.
* This 'configuration' will likely have activations of connection
factories and admin objects too
> These resource definitions for CF and AO, refer to that existing RA
> instance, through the resourceAdapterName annotation element or
> resource-adapter-name deployment descriptor element by specifying
> 'myeis' as the name. The container now uses the 'myeis' instance for
> creating the CF and AO.
>
* The config-property's are done separate from the annotation
activations, making users have to look in different places to get the
entire picture
These two gives
Configuration Annotations
(CF) CF
| |
RA-------------
| |
(AO) AO
which doesn't make it clearer for the user IMHO.
> Having more than one deployments of the same RAR is an advanced
> scenario, but again this is handled through the above scheme. The
> administrator through vendor-specific tools have rarinstance1 and
> rarinstance2 as two deployments of the same RAR (eis.rar), and the
> resource definition annotations can refer to them through the
> resource-adapter-name.
>
* It is assumed that multiple activations of the same top-level resource
adapter deployment can be uniquely identified
Something we havn't touched, and it just adds to the complexity of the
above picture.
> The ResourceAdapterAssociation interface only defines the methods to
> associate a ResourceAdapter object with other objects that implement
> this interface like ManagedConnectionFactory and ActivationSpec. The
> container would automatically set the MCF with the right RA instance
> using the value of resourceadapterName.
>
Yes, but it very important that the user is clearly able to identify
which resource adapter instance the CF/AO/... is associated to.
> I agree, but these resource definition annotations makes it simpled for
> the most-common-case scenarios where a developer needs to just define a
> CF and use it. For production scenarios, as always, the administrator
> can override these settings through DDs, and also set metadata-complete
> to prevent scanning of these annotations.
>
Sometimes it is good to take a step back and look at the entire picture.
We are trying to come up with something that will help users with their
activations in a clear manner.
Our goal is to make it clearer and simpler than the way it is today, by
1) Vendor deployment tool
2)
public class MyServlet implements ...
{
@Resource(mappedName="java:/eis/ConnectionFactory")
private ConnectionFactory cf;
Yes, there is a lot of glue between 1) and 2), but that makes this area
tricky to get right.
Best regards,
Jesper