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.