Hi Jesper
On Monday 17 December 2012 09:38 PM, Jesper Pedersen wrote:
> Hi,
>
> On 12/17/2012 09:56 AM, Sivakumar Thyagarajan wrote:
...
>>> 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.
As suggested below, we don't need to recommend this.
>> 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.
Ok.
>>> 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".
If a user wants to have a vendor-specific property to enforce a QoS for
their CF, they can always be specified or overridden through
deployment-descriptor or vendor-specific dd during deployment. We are
talking about most scenarios where the developer is fine with the default
pool settings offered by a vendor during development.
> 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.
If there is enough interest in standardizing that and as long as most
existing implementations support them, we can standardize security
settings. Do you think a lot of basic developer scenarios would require
specification of security settings?
> 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.
It is upto the application server implementation to define a scheme to
differentiate properties that are meant for the MCF and properties that
are meant for the container. For instance, using the above scheme, a "."
(or any other delimiter like '_' that is not a valid MCF property
character) in a property name is not a valid MCF JavaBean property. So,
the container can always handle any property with a ".", and pass on all
other properties to the MCF.
> ...
[Moving the discussion multiple resource adapter deployment instances
scenario discussion to another sub-thread]
>>> 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.
The <connector-connection-factory> element would be defined in the
javaee_7.xsd schema, and this uses an unbounded list of propertyType
elements. So, all resource definition annotations (like
DataSourceDefinition, JMSConnectionFactoryDefinition and
ConnectorConnectionFactoryDefinition) would have the property section as
shown in the example in page 2.
Thanks
--Siva.