Linda,
Comments below:
# What other defaults do you think should be standardized on?
- Here is what I think (basically copied from Resin):
Data source:
* description: ""
* name: required
* class name: DataSource
* server name: null - must be ignored unless specified or maybe "localhost"?
* port number: null - must be ignored unless specified
* database name: null - must be ignored unless specified
* url: null - must be ignored unless specified
* user: ""
* password: ""
* property: empty
* login timeout: 30
* transactional: true
* isolation level: read committed
* initial pool size: 0
* max pool size: 1024
* min pool size: 0
* max idle time: 30
* max statements: we don't have one, but it would be good to have some
guideline from the standard. Also, don't quite understand the purpose?
* Maybe add connection re-try, prepared statement cache and backup
url/driver?
JMS connection factory:
* description: ""
* name: required
* resource-adapter-name: null - must be ignored unless specified
* resource-type: javax.jms.ConnectionFactory
* user: ""
* password: ""
* clientId: null - must be ignored unless specified
* max-pool-size: 1024
* property: empty
* connection-timeout: 30
* transactional: true
* initial-pool-size: 0
* min-pool-size: 0
* max-idle-time: 30
JMS destination:
* description: ""
* name: required
* resource-type: javax.jms.Queue
* resource-adapter: null - must be ignored unless specified
* resource-name: null - must be ignored unless specified
* property: empty
Mail session:
* description: ""
* name: required
* store-protocol: IMAP?
• store-protocol-class: null?
• transport-protocol: SMTP?
• transport-protocol-class: null?
• host: localhost?
• user: ""
• from: null?
• property: empty
The advantage of the empty String is that it is usable/deterministic
even if it is not explicitly specified. From a user perspective, it
might be annoying to specify things like <password></password>. In case
of annotations, this is easy to do (and I think it's done right for the
data source annotations if I remember correctly) but it's trickier with XML.
# Java EE currently standardizes on database, JMS, and mail as resources
that must be provided.
- I know, but it's pretty tenuous. I was wondering about making it more
concrete like JNDI name, type, etc.
# Do your suggestions mean that you otherwise agree with the form in the
proposal?
- Yes, it looks pretty good.
# All of them? Or which ones? Are there any others?
- Comments above.
# Do you like the XML illustrated in the straw man?
- Yes.
Cheers,
Reza
On 7/27/2011 8:58 PM, Linda DeMichiel wrote:
> Hi Reza,
>
> Thanks for the feedback. Some comments and questions from me below....
>
> On 7/27/2011 3:29 PM, Reza Rahman wrote:
>
>> Linda,
>>
>> Looks good overall.
>>
>> A few questions:
>> * Should more configuration defaults be standardized? Some of what is
>> now required could simply be defaulted. It could
>> be problematic if some of the values defaulted to "null" instead of
>> an empty string.
>
> That is a question that we would really like feedback from you and the
> other experts on.
> What other defaults do you think should be standardized on?
>
> I'm not following your comment about null vs empty string though.
> Could you explain further?
>
>> * Should we standardize some default resources that an application
>> server must provide?
>
> Java EE currently standardizes on database, JMS, and mail as resources
> that must be provided.
>
>> * Since JMS pluggability is not well defined, how portable is the
>> proposed JMS resource configuration really?
>
> We believe that JCA covers the issue of JMS pluggability. An
> application could potentially
> bundle a JMS resource adapter and reference it in the configuration
> information instead of
> relying on the default JMS implementation bundled with the appserver.
>
>> * The names <jms-resource>, <jms-admin-object> and <mail-resource>
>> seem overly abstract/ivory-tower-ish. Is there a
>> reason for that - it might confuse the average joe developer? Why not
>> simply use <jms-connection-factory>,
>> <jms-destination> and <mail-session>?
>>
>
> Sure! I needed a strawman element name to convey the semantic intent,
> but we are very open
> to suggestions for better names. We wanted first of all to get
> feedback on the form in which
> this configuration metadata should be specified. Do your suggestions
> mean that you otherwise
> agree with the form in the proposal?
>
>> Comments on your notes:
>> * What happens upon failure to satisfy the requested resources? Does
>> the application fail to deploy or is there run-time
>> failure?
>> - There should be a deployment failure - basically the "fail fast"
>> principle.
>> * Should any of the following attributes be standardized, or should
>> they be left as properties?
>> - They should be standardized.
>
> All of them? Or which ones? Are there any others?
>
>> * Do we need any way to distinguish XA from non-XA if transactional?
>> - I don't think we do. If so, it should be a separate attribute.
>> * Should this creation be limited to cloud environments?
>> - No.
>> * What format should the specification of an application’s resource
>> configuration dependencies take, particularly when
>> the application is intended for multi-tenant Resource Configuration
>> July 26, 2011 3:20 pm 11 use?
>> - Not sure I understand?
>
> Do you like the XML illustrated in the strawman? It could plausibly
> be expanded with elements
> or attributes that would indicate which information could / should /
> or must not be modified
> when the application is deployed for another tenant. Alternatively,
> what would you suggest?
>
>> * What means should we use to indicate sharing of resources?
>> * We will need a means to specify which attributes of the resource
>> definition must be modified by a tenant, which
>> attributes of the resource definition must not be
>> modified when the application is deployed for a tenant, and which
>> attributes of the resource definition may be modified
>> by a tenant.
>> - Probably just more attributes? Difficult to tell without actually
>> seeing the rest of the multi-tenancy features.
>>
>> Hope it helps.
>>
>
> Yes -- thank you!
>
> regards,
>
> -Linda
>
>> Cheers,
>> Reza
>>
>>
>> On 7/26/2011 6:42 PM, Linda DeMichiel wrote:
>>> One of our goals in this release is to provide improvements in
>>> resource configuration and resource "definition". The intention here
>>> is both to enable the deployment process to be further automated in
>>> PaaS environments and to facilitate ease-of-use.
>>>
>>> Resource definitions (for example, the DataSource definition
>>> introduced in Java EE 6), allow an application to be deployed into the
>>> cloud with more minimal administrative configuration, and can also
>>> serve as "templates" for modifications and/or extensions to meet the
>>> deployment requirements of additional tenants.
>>>
>>> The attached document is intended as a proposal for the first step in
>>> this process, and addresses standardization for the configuration of
>>> application-scoped resources that are required to be provided as
>>> part of the platform.
>>>
>>> We would appreciate if you would review this document in detail and
>>> post your feedback. There are a number of issues flagged in the text,
>>> including open issues that impact on the next steps that we would
>>> pursue in extending such configuration support to multiple tenants.
>>>
>>> thanks,
>>>
>>> -Linda
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG -www.avg.com
>>> Version: 10.0.1390 / Virus Database: 1518/3789 - Release Date: 07/26/11
>>
>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1390 / Virus Database: 1518/3792 - Release Date: 07/27/11
>
>