users@connector-spec.java.net

[connector-spec-users] [jsr322-experts] Re: Choice of Package

From: Sivakumar Thyagarajan <sivakumar.thyagarajan_at_oracle.com>
Date: Fri, 28 Dec 2012 23:41:47 +0530

Hi Jesper

On Friday 21 December 2012 02:13 PM, Jesper Pedersen wrote:
> Hi,
>
> On 12/20/2012 12:47 PM, Sivakumar Thyagarajan wrote:
>>> Furthermore placing the annotations in javax.resource would give an
>>> indication that those could be used in a standalone environment for the
>>> supported component model(s). So we need to call it out explicit that
>>> supporting these annotations would be up to the vendor.
>>
>>
>> Why does javax.resource indicate use for standalone environment. Today
>> we define the javax.resource package
>> (http://docs.oracle.com/javaee/6/api/javax/resource/package-summary.html) as
>>
>> just a "top-level package" for the Connector specification.
>>
>
> Because the annotations would be defined in the JCA spec, if they are in
> javax.resource. Hence we need to make support optional for standalone
> (chapter 3.5).

The javax.resource package has no connotation of required/optional
associated to it per se, but I agree with a point you make below.

>> However for existing EE technologies such as JMS and connectors, the new
>> resource definition annotations must be placed in their own existing
>> packages (javax.jms and javax.resource respectively).
>>
>
> If javax.resource is going to be mandated, we need to at least put them
> into their own package, javax.resource.deployment.
>
>>> Another reason is that since they are optional for the standalone JCA
>>> environment they would make more sense to place in the full profile EE
>>> specification together with @DataSourceDefinition.
>>
>> I don't think we took a decision on supporting
>> @ConnectorConnectionFactoryDefinition in standalone connector
>> containers. AFAIK, support for the EoD annotations defined in Chapter 18
>> are not exempt for a standalone connector container.
>>
>
> Those are different, those are for development. Those are a priority for
> the spec, and must be supported.

You are right that there is a difference between the Chapter 18 EoD
annotations (which are used by the RA developer to describe their resource
adapter artifacts) and the proposed resource definition annotations (which
are used by an application component developer to define a resource based
on the RA).

The former needs to be supported by a standalone connector container.
Whereas in the latter case, if the standalone connector container supports
an application component container that supports the definition of these
resource definition annotations, only then must the standalone connector
container support these annotations in the context of that application
component. So, I agree that the standalone connector container environment
section(3.5) must not generally mandate the support for these annotations.
I will come up with verbiage which describes this and share it for review.

Thanks
--Siva.

> But the standalone container doesn't mandate a component model, e.g.
> servlet, EJB, ..., and therefore there is no place to put these
> annotations for deployment. So they can't be verified in the standalone TCK.
>
> Even though the standalone profile of IronJacamar includes a servlet
> container I have no interest in supporting these annotations for
> activation. Hence "Open to Community".
>
> Other component models may even not support annotations.
>
> Best regards,
> Jesper
>