Hi Jesper
On Monday 17 December 2012 09:38 PM, Jesper Pedersen wrote:
> Hi,
>
> On 12/17/2012 09:56 AM, Sivakumar Thyagarajan wrote:
>>> But lets start by discussing the actual deployment.
>>>
>>> These annotations can't be top-level annotations, since a
>>> configuration of
>>> the ResourceAdapter config-property's are needed. Just having a
>>> 'resourceAdapterName' isn't enough.
>>
>> Are you talking about a scenario where a single resource-adapter module
>> (say foo.rar) may be deployed multiple times (each of them given a name
>> by the deployer, say foo-1, foo-2 and foo-3) in a container with
>> different resource-adapter-configurations, and we should have the
>> capability to refer to one of these deployed instances?
>>
>
> 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).
So, with this background, please see inline.
>>> Also they need to be scoped to account for ResourceAdapterAssociation
>>> implementations. This is very important.
>>
>> I couldn't understand this. Could you please elaborate?
>>
>
> We need to scope the annotations under a specific resource adapter
> instance in order for them to share information.
>
> ResourceAdapter:
> - String raValue;
>
> MCF implements ResourceAdapterAssociation:
> - uses raValue
>
> AO implements ResourceAdapterAssociation:
> - uses raValue
>
>
> And we could have multiple "pairs" - each with their own 'raValue' value
> (different JNDI bindings of course).
>
> @ResourceAdapterDeployment
> (
> resource-adapter="eis.rar"
>
> @ResourceAdapterConfiguration(
> config-properties=
> {{"raValue", "value1"}}
> )
This is done out-of-band as explained above, and the eis.rar deployment is
now available with a name in the application server, say "myeis".
> @ConnectionFactoryDefinitions(
> @ConnectionFactoryDefinition(
>
> )
>
> @ConnectionFactoryDefinition(
>
> )
> )
>
> @AdminObjectDefinitions(
> @AdminObjectDefinition(
>
> )
>
> @AdminObjectDefinition(
>
> )
> )
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.
> )
>
> and so on - f.ex. using the same resource adapter to access a local and a
> remote messaging system - e.g. 2 @ResourceAdapterDeployment. We are
> almost close to having the same number of annotations for activation that
> we have for development.
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.
> Having the annotations "unscoped" would make it impossible to know which
> ResourceAdapter instance they should associate with.
>
> We should keep advocating ResourceAdapterAssociation usage for vendors, in
> order to ease the activation of resource adapters.
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.
> I understand the need for annotations in development to make it easier for
> developers. However, I also believe that JCA belongs in its own category,
> as finding a missing JCA vendor container setting in Java code isn't as
> trivial as trouble shooting a wrong path for a servlet; I'll return to the
> 'overrides' question later...
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.
Thanks
--Siva.