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
- 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?
- 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.
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.