Hi Jesper
Thanks for your comments. Please see inline.
On Friday 21 December 2012 02:48 PM, Jesper Pedersen wrote:
> Hi,
>
> On 12/20/2012 12:47 PM, Sivakumar Thyagarajan wrote:
>> 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.
>>
>
> Yes, but a vendor may require other mandatory properties that aren't
> defined by the annotations.
>
> Require them to be defined in the "properties" map, or in the deployment
> descriptor. We have a mandatory 'pool-name' to uniquely defined the object
> in our management model; that would have to be specified in 'properties'
> or in the deployment descriptor override.
>
> Just saying, that no matter how many attributes we put on these
> annotations we won't cover all scenarios.
I agree. We can't cover *all* scenarios and I just want the spec to cover
*most* scenarios. For scenarios that can't be covered by the spec, there
are existing vendor-specific administrative tools to create those
resources to cover those corner-case scenarios.
Do you have any other properties, apart from the min-pool-size and
max-pool-size attributes, that we could standardize to cover more common
scenarios?
The DataSourceDefinition annotation (TABLE 2-10 in the common annotations
spec) defines a bunch of properties. Unfortunately the connector spec, has
never standardized a set of CF or pool properties. So, beyond a pool size
which I thought most CF implementations would already have, I couldn't
think of any other properties without the risk of treading on existing
implementations. However, if there is anything else you would like to have
added, please let this thread know and we can see if all implementations
can handle them.
>>> 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?
>>
>
> Security settings helps to separate the internal pools based on Subject
> and ConnectionRequestInfo, so they are used.
>
> Of course a vendor can choose how to implement their internals, but we
> need to make it clear to the user how the container will look at the
> credentials used.
>
> @Security
> NO_SECURITY -- All Subject / CRI to sent to the same pool
> SUBJECT -- Pools are split on Subject equality
> CONNECTION_REQUEST_INFO -- Pools are split on ConnectionRequestInfo
> equality
> SUBJECT_AND_CONNECTION_REQUEST_INFO -- Advanced scenario where both
> parameters are taken into account for splitting
>
Do you think most connector container implementations support this
feature? AFAIK, GlassFish doesn't support this. Would you consider this
setting a fairly advanced 'deployment' configuration, and have this be
specified through vendor-specific properties?
As an example, GF also supports a list of advanced pooling features (see
attributes in
http://docs.oracle.com/cd/E19798-01/821-1750/giygu/index.html), but they
may not be of interest to other implementations, and so I avoided them in
the inital @ConnectorConnectionFactoryDefinition proposal.
My thumb rule that I am trying to use here: We should standardize the
'core' widely-implemented set of CF configuration properties, that a
developer who is going to use a Connector CF would need in 80% of their
usecase scenarios on any application server?
Thanks
--Siva.
> We would need a String parameter for SUBJECT and
> SUBJECT_AND_CONNECTION_REQUEST_INFO in order to specify the security
> domain they relate to.
>
> If the resource adapter supports reauthentication, that is a separate
> pool, but we don't need that option in @Security IMHO. Having a top-level
> override is better
>
> @ResourceAdapterDefinition(
> Boolean reauthentication;
> )
>
> @Security should be mandatory, without a default value.
>
>> 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.
>>
>
> Correct.
>
>> 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.
>
> Ok.
>
> Best regards,
> Jesper
>