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.
>> 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
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