Hi Jesper
Thanks a lot for your quick comments. Sorry for the delay. Please see
inline for my comments.
On Thursday 13 December 2012 08:23 PM, Jesper Pedersen wrote:
> 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.
Could you help me understand how the use of javax.resource package is tied
to standalone environments?
> 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?
> 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?
> 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".
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.
> 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.
> 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.
> However, the "properties"
> map would have to be used in many cases in order to account for vendor
> specific pool settings.
>
Yes.
> 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?
> Also they need to be scoped to account for ResourceAdapterAssociation
> implementations. This is very important.
I couldn't understand this. Could you please elaborate?
Thanks
--Siva.
> Best regards,
> Jesper
>
> 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?