Hi,
On 12/13/2012 06:54 AM, Sivakumar Thyagarajan wrote:
> Could you please share your comments and inputs on this?
>
Some initial thoughts.
Package name:
If javax.resource is to be used, then the functionality should be made
optional for standalone environments.
I would suggest using javax.annotation.resource as the package name.
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.
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.
Side note: @DataSourceDefinition from EE 6 suffers from the same
problem, making it not very usable in real life.
Min-pool-size / Max-pool-size:
I think they should be scoped under a <pool>. However, the "properties"
map would have to be used in many cases in order to account for vendor
specific pool settings.
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.
Also they need to be scoped to account for ResourceAdapterAssociation
implementations. This is very important.
Best regards,
Jesper
P.S. The example on page 2 isn't in sync with the actual definition.