Hi Siva,
Do you mean that an adapter can define connection/AO resources only, but can NOT refer to or lookup them inside the adapter?
One question: These resources may be used most commonly for testing or demo, so in a product env, how can deployers disable them? I understand that vendors can provide their own solutions, just want to know whether it makes sense to define a standard solution.
If this disable action would require deployers to unpack the RAR and then update DD, it actually create extra burden, so may be opposite to the original 'EoD' intention.
I guess many vendors already have its own mechanism to deploy pools/AO resources etc at the same time when deploying the adapter, such as WebLogic uses weblogic-ra.xml packaged inside RAR; so I am not sure how much benefits this feature can bring to users, especially many advanced settings such as pool parameters/security/logging etc have to be specified in vendor specific ways for any non-trivial resource definitions. Anyway, if others prefer to have it, I am fine.
Thanks
Wilson
> -----Original Message-----
> From: Sivakumar Thyagarajan
> Sent: Friday, December 21, 2012 2:31 PM
> To: jsr322-experts_at_connector-spec.java.net
> Cc: Wilson Tian
> Subject: Re: [jsr322-experts] Re: 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 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.
>