On Tuesday 18 December 2012 08:31 PM, Frederick W Rowe wrote:
> I believe we need to update the JCP page for JSR322 to set it's status to
> "Maintenance" (currently "Final") and perhaps update the Spec Lead to
> indicate that Binod is not a spec lead? OR does that only occur when the
> draft of the MR spec is published?
Thanks Fred for pointing this out. I will work with the JCP PMO to see how
we can address this.
Thanks
--Siva.
>
> Regards,
>
> Fred Rowe
>
> WebSphere Architect
> Senior Software Engineer
> IBM Software Group
>
>
>
> Jesper Pedersen <jesper.pedersen_at_redhat.com>
> 12/17/2012 11:08 AM
> Please respond to
> jsr322-experts
>
>
> To
> jsr322-experts_at_connector-spec.java.net
> cc
>
> Subject
> [connector-spec-users] [jsr322-experts] Re: Connector CF Resource
> Definition annotation - a proposal and request for comments.
>
>
>
>
>
>
> 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.
>
> 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.
>
>>> 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.
>
> 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.
>
> They are aiming to do the same thing. We can always discuss the
> usefulness of it ;)
>
>>> Class name:
>>>
>>> I would use the class name of the ManagedConnectionFactory as the class
>>> name of the Connection Factory can lead to situations where it isn't
>>> clear
>>> which MCF should be used, like
>>>
>>> SuperInterface
>>> |
>>> |-- SubInterface1 --> MCF1
>>> |
>>> |-- SubInterface2 --> MCF2
>>>
>>> where 'SuperInterface' is used in the definition. JMS has hierarchies
>>> like
>>> this.
>>
>> As per the connectionfactory-interface-uniqueness in the schema (CODE
>> EXAMPLE 20-1 of the Connectors 1.6 spec), there must be only
>> connection-definition with a connectionfactory-interface. An MCF can be
>> shared by multiple connection definitions.
>>
>> So, in the case described above, the JMS RA would define 3
>> connection-definitions, namely: cd1(with say MCF0) for SuperInterface,
>> cd2(with MCF1) for SubInterface1 and cd3 for SubInterface2(with MCF2).
>> The connector container then given the connection-factory-interface
>> alone should be able to figure out the right connection-definition,
> right?
>>
>
> It would be 2 MCFs with their unique CF (SubInterface1 and
> SubInterface2) -- SuperInterface would be an implementation detail. But
> the user would use SuperInterface in their code.
>
> I know it has been like this since the beginning of the spec. However,
> spec is one thing, and vendors does something else ;)
>
>>> Properties:
>>>
>>> These properties are very error prone, as they relies on vendor
> specific
>>> strings, some of which would be mandatory, like security settings.
>>>
>>> Vendors could have to agree to use namespaces, such that properties
>>> doesn't overlap, like
>>>
>>> {"ironjacamar.security", "security-domain"},
>>> {"ironjacamar.security.domain", "MySecurityDomain"},
>>> {"ironjacamar.pool.pad-xid", "true"}
>>>
>>> Furthermore the component using the definition would have to account
> for
>>> all JCA containers.
>>
>> Any property name/value specified through the properties annotation
>> element, that is not specific to the connector container, is opaque to
>> the container and is used as-is to set a property on the MCF JavaBean.
>> So, should we even standardize that these properties have a
>> vendor-specific prefix like "ironjacamar".
>>
>
> A recommended approach at least.
>
>> Any value specified in the properties annotation element of the
>> ConnectorConnectionFactoryDefinition annotation can be overridden using
>> the deployment descriptor. So, even if the deployment environment uses a
>> different vendor's RA (whose MCF has different property names) or a
>> different contained that has a different property, this could be
>> overridden using the DD, right, thus obviating the need to define any
>> such schemes.
>>
>
> Hmm... Let me get back to this after some thought.
>
>>> Side note: @DataSourceDefinition from EE 6 suffers from the same
> problem,
>>> making it not very usable in real life.
>>
>> Could you give an example where the current support in
>> DataSourceDefinition is not very usable. Maybe that would help us think
>> about this better.
>>
>
> In the next specification revision - not this one - I think we should
> investigate if we could agree on a "baseline" level of activation
> properties for connection factories and admin objects. Maybe even
> default values...
>
> Then we should build out the annotations with those.
>
> Using vendor specific properties like the above isn't very developer
> friendly. And for @ConnectionFactoryDefinition we already know that it
> isn't enough, making the 'properties' field "mandatory".
>
> The "properties" will always used to enable vendor specific features.
> But IMHO it is wrong to not allow a basic @CFD to activate without a
> 'properties' definition; like we are missing security settings atm.
>
> So I think that the @CFD and @AOD work should be done as part of that.
>
>>> Min-pool-size / Max-pool-size:
>>>
>>> I think they should be scoped under a <pool>.
>>
>> What do you mean by "scoped"? Are you suggesting that we have a <pool>
>> element in the DD schema? I don't understand the need for one, since we
>> don't have a similar separation for DataSourceDefinition.
>>
>
> Precisely ;) Leading to "What is scoped, and what is not ?" type
> questions from users. Min-pool-size is top-level, where as
> "ironjacamar.pool.pad-xid" isn't.
>
>>> But lets start by discussing the actual deployment.
>>>
>>> These annotations can't be top-level annotations, since a
>>> configuration of
>>> the ResourceAdapter config-property's are needed. Just having a
>>> 'resourceAdapterName' isn't enough.
>>
>> Are you talking about a scenario where a single resource-adapter module
>> (say foo.rar) may be deployed multiple times (each of them given a name
>> by the deployer, say foo-1, foo-2 and foo-3) in a container with
>> different resource-adapter-configurations, and we should have the
>> capability to refer to one of these deployed instances?
>>
>
> One or more, yes.
>
>>> Also they need to be scoped to account for ResourceAdapterAssociation
>>> implementations. This is very important.
>>
>> I couldn't understand this. Could you please elaborate?
>>
>
> We need to scope the annotations under a specific resource adapter
> instance in order for them to share information.
>
> ResourceAdapter:
> - String raValue;
>
> MCF implements ResourceAdapterAssociation:
> - uses raValue
>
> AO implements ResourceAdapterAssociation:
> - uses raValue
>
>
> And we could have multiple "pairs" - each with their own 'raValue' value
> (different JNDI bindings of course).
>
> @ResourceAdapterDeployment
> (
> resource-adapter="eis.rar"
>
> @ResourceAdapterConfiguration(
> config-properties=
> {{"raValue", "value1"}}
> )
>
> @ConnectionFactoryDefinitions(
> @ConnectionFactoryDefinition(
>
> )
>
> @ConnectionFactoryDefinition(
>
> )
> )
>
> @AdminObjectDefinitions(
> @AdminObjectDefinition(
>
> )
>
> @AdminObjectDefinition(
>
> )
> )
> )
>
> and so on - f.ex. using the same resource adapter to access a local and
> a remote messaging system - e.g. 2 @ResourceAdapterDeployment. We are
> almost close to having the same number of annotations for activation
> that we have for development.
>
> Having the annotations "unscoped" would make it impossible to know which
> ResourceAdapter instance they should associate with.
>
> We should keep advocating ResourceAdapterAssociation usage for vendors,
> in order to ease the activation of resource adapters.
>
>
> I understand the need for annotations in development to make it easier
> for developers. However, I also believe that JCA belongs in its own
> category, as finding a missing JCA vendor container setting in Java code
> isn't as trivial as trouble shooting a wrong path for a servlet; I'll
> return to the 'overrides' question later...
>
>>> P.S. The example on page 2 isn't in sync with the actual definition.
>>
>> Are you referring to the differences in the name
>> (<name>java:app/MyEISConnectionFactory</name>
>> in the DD and name="java:comp/eis/MyEISCF"). If yes, that was a typo and
>> sure I will fix it. Thanks for pointing that out. Are there any other
>> differences that I am missing?
>
> It should be:
>
> <properties>
> <property>
> <name>
> <value>
> </property>
> </properties>
>
> to align with the "properties" map.
>
> Best regards,
> Jesper
>
>
>