Hi Jesper
I am splitting my responses to your comments into separate sub-threads for
readability and tracking sake. Hope this is fine with you.
Thanks
--Siva.
On Monday 17 December 2012 09:38 PM, Jesper Pedersen wrote:
> Hi,
>
> On 12/17/2012 09:56 AM, Sivakumar Thyagarajan wrote:
>>> Package name:
>>>
>>> If javax.resource is to be used, then the functionality should be made
>>> optional for standalone environments.
>>
>> Could you help me understand how the use of javax.resource package is
>> tied to standalone environments?
>>
>
> Using javax.resource would break the existing signature test in standalone
> TCK and full profile TCK.
As I had said earlier, this MR would result in a new spec-version 1.7, and
hence a new TCK version (and a corresponding sig-test version). So this
should be ok.
> 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.
>>> I would suggest using javax.annotation.resource as the package name.
>>
>> If we had an existing package already for a spec (like javax.resource in
>> our case), would it make sense to reuse the same package for the new
>> resource definition annotations that are defined in EE7?
>>
>
> I suggested javax.annotation.resource because the @DataSourceDefinition is
> specified in javax.annotation.sql, and this is related.
Yes, this is interesting.
JDBC as a technology is applicable both in the SE and EE platforms. The
@DataSourceDefinition was a Java EE only annotation, and hence was defined
in the common annotations spec, and placed in a common package such as
javax.annotation.sql instead of javax.sql or java.sql (which are also
applicable in SE).
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).
> 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.
> They are aiming to do the same thing. We can always discuss the usefulness
> of it ;)
> ...
[rest covered in other threads]
Thanks
--Siva.