Hi Jesper
On Friday 21 December 2012 07:06 PM, Jesper Pedersen wrote:
> 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.
Yes, precisely.
> A couple of points.
>
> * This 'configuration' will likely have activations of connection
> factories and admin objects too
>
I see the configuration of the RA as being a distinct act (Section
5.3.7.1) from the configuration of MCF (5.3.7.5) and AO (13.4.2.4). The
configuration of the former is out-of-band and is performed by the system
administrator through application-server-specific tools as explained
above. The latter may be done through vendor-specific tools or through the
new resource definition annotations.
> > 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
>
I may not have understood this correctly. Are you talking about
@ConfigProperty or the properties annotation element in the resource
definition annotations?
> 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
Yes.
> 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.
Yes, completely agree. This is done through the resourceAdapterName
annotation element.
>> 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.
I agree, and your suggestions are welcome. As of now, we are trying to
define RA activation (as described earlier in this thread), as it has been
traditionally a deploy-time activity. EE7 is looking at simplifying
resource definitions once we have a RA activation.
Thanks
--Siva.