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