Reza,
On Thu, Jul 28, 2011 at 12:29 AM, Reza Rahman <reza_rahman_at_lycos.com> 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.
> * Should we standardize some default resources that an application server
> must provide?
> * Since JMS pluggability is not well defined, how portable is the proposed
> JMS resource configuration really?
> * 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>?
>
> 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.
>
That's a good point, especially if configuration may even be backed by a DB
like the cases Adam just mentioned.
Falling back to default would in such case only make sense, if every single
configuration is also stored like that or exists on a file basis.
> * Should any of the following attributes be standardized, or should they be
> left as properties?
> - They should be standardized.
> * 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.
>
+1 and telling from the troubles XA vs. non-XA caused them in a recent
project, I strongly suggest, there should be a distinction.
Would have helped those colleagues a lot.
* 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?
> * What means should we use to indicate sharing of resources?
>
I guess that applies to multi-tenancy, let's say 2 or more instances share
the same DB.
> * 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.
>
> Cheers,
> Reza
>
>
Cheers,
Werner
>
>
> 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
>
>
>
>
--
Werner Keil | UOMo Lead | Eclipse.org
Twitter @wernerkeil | Skype: werner.keil | www.eclipse.org/uomo |
#EclipseUOMo
* JavaOne: October 2-6 2011, San Francisco, USA. Werner Keil, Agile Coach,
UOMo Lead will co-present "JSR 321: Trusted Java API"