Hi Wilson
On Friday 21 December 2012 08:13 AM, Wilson Tian wrote:
> Hi Siva,
>> I agree that the lack of a component namespace for resource adapters is a problem, and hence allowing a resource
>> definition annotation in resource adapters to place resources in java:comp or java:module is a challenge.
>> One alternative is to only allow resource adapters to create java:app or java:global resources. This works and
>> is okay until we define a component namespace for RAs, but is it the best approach? I would love to hear from
>> you and others in the EG on this.
>
> If java:app and java:global is allowed for resource definition annotation in resource adapters, there may be some issues:
> - schema of ra.xml should be updated to allow DD overriding the annotations
Yes ra.xml schema must allow the DD equivalents of the resource definition
annotations, if we agree that a resource adapter is allowed to specify
these resource definition annotations. One of the usecases to allow this,
is to enable single-click deployment of RAs and make some well-known CF
and AO resources for use by applications later.
> - should adapter be allowed to define or refer to other standard EE resources, such as define a DataSource or refer to other DataSource/EJB, using annotation or in ra.xml?
This is a good question. EE.5.2.2 explicitly prevents the definition of
Resource annotations in RAs.So, EJB refs and datasource refs are out. If a
resource adapter is allowed to define a Datasource, the RA may not be able
to use it (look it up), as it doesn't have a component namespace of its
own. So, I would prefer we not allow @DataSourceDefinition and other
annotations.
> - java:global may be fine, but how to describe exactly when java:app should be resolved to adapter's APP name space, and when to caller's name space? This is long-standing question we ever discussed but did not get clear answer yet.
Sorry, I should have been clearer in my earlier email. There are two
scenarios.
1. Defining a resource definition annotation inside an embedded RAR
2. Defining a resource definition annotation inside a standalone RAR
For the former, allowing java:global and java:app may be possible.
For the latter, allowing java:global alone makes sense.
Thanks
--Siva.
>
> Thanks
> Wilson
>
>
>> -----Original Message-----
>> From: Sivakumar Thyagarajan
>> Sent: Friday, December 21, 2012 2:21 AM
>> To: jsr322-experts_at_connector-spec.java.net
>> Cc: Jesper Pedersen
>> Subject: [jsr322-experts] Resource definition annotation related changes to Platform Spec (WAS: Re: Re:
>> [connector-spec-users] Connector CF Resource Definition annotation - a proposal and request for comments.)
>>
>> Hi Jesper
>>
>> On Wednesday 19 December 2012 02:17 PM, Jesper Pedersen wrote:
>>> On 12/13/2012 06:54 AM, Sivakumar Thyagarajan wrote:
>>>> Could you please share your comments and inputs on this?
>>>>
>>>
>>> Other changes to the Platform spec:
>>>
>>> 1) Ok, to add the interface name
>>
>> Ok, thanks.
>>
>>> 2) Yes, application clients should be excluded
>>
>> I went back and checked the EE spec and our spec, and it appears that we don't /require/ support for Connectors
>> in application clients, but vendors may choose to do so. So, we cannot exclude it, but we don't need to require
>> support for the resource definition annotations in application clients.
>>
>>> 3) Same as 2) - application clients should be excluded
>>>
>>>
>>> Open questions:
>>>
>>> 1) I would suggest
>>>
>>> @ResourceAdapterActivation / @ResourceAdapterDeployment
>>> @ResourceAdapterDefinition
>>> @ConnectionFactoryDefinitions
>>> @ConnectionFactoryDefinition
>>> @AdministeredObjectDefinitions
>>> @AdministeredObjectDefinition
>>>
>>> With a package name of javax.annotation.resource
>>>
>>> We should also aim at having annotations for "sub-areas" of the
>>> activation
>>> - like @Pool
>>
>> Let us discuss the need for ResourceadapterActivation in the thread with the subject 'Support for Resource
>> Adapter Configuration/Deployment through annotations?'.
>>
>>> 2) I'm ok with using '#' as the separator. However, we should use the
>>> full names of the modules, e.g.
>>>
>>> <module-name>a.ear#r.rar</module-name>
>>>
>>> in order to allow for vendor specific deployment formats.
>>
>> I will start a separate thread on this. Naming is a complicated issue :)
>>
>>> 3) Ok, and the same for the resource adapter and admin objects
>>
>> Ok, thanks.
>>
>>> 4) We can do min-pool-size / max-pool-size (scoped under pool). Other
>>> standard properties should be made in a future revision of the
>>> specification
>>
>> Ok, makes sense.
>>
>>> 5) Deployments to component namespaces (java:global, ...) should be
>>> excluded in this revision.
>>
>> I assume you want this restriction only for resource definition annotations placed in resource adapter modules.
>> Do you have a particular reason for this restriction? What would be the use if we don't allow a registration to
>> any component namespace.
>>
>>> 6)
>>> i) Component namespaces are excluded for deployment in general
>>> ii) Ok, and the same for the activation in general
>>> iii) Ok, and the same for the activation in general
>>>
>>>
>>> General comment:
>>>
>>> We need to exclude component namespaces in this revision such that we
>>> aren't restricted once we start to work on standardizing JNDI
>>> locations and component namespaces. Once these policies are in place
>>> we can update the policies for the annotations based on the outcome.
>>
>> I agree that the lack of a component namespace for resource adapters is a problem, and hence allowing a resource
>> definition annotation in resource adapters to place resources in java:comp or java:module is a challenge.
>> One alternative is to only allow resource adapters to create java:app or java:global resources. This works and
>> is okay until we define a component namespace for RAs, but is it the best approach? I would love to hear from
>> you and others in the EG on this.
>>
>> Thanks
>> --Siva.