Bongjae,
Thanks a lot. Looking forward to your thoughts on what we discussed so far.
Have a nice weekend,
Werner
On Fri, Sep 2, 2011 at 4:46 AM, Bongjae Chang <bongjae.chang_at_gmail.com>wrote:
> Hi Linda,
>
> I will send you feedback and opinions by next week.
>
> Thanks.
>
> Regards,
> Bongjae Chang
>
>
> On 9/2/11 5:46 AM, "Linda DeMichiel" <linda.demichiel_at_oracle.com> wrote:
>
> >Reza,
> >
> >Thanks very much for the thoughtful and detailed feedback.
> >
> >I'm going to hold off commenting further for now -- because I want
> >a dialogue from the group, not myself.
> >
> >Folks, could the rest of you please weigh in on all the issues!
> >
> >thanks,
> >
> >-Linda
> >
> >
> >On 8/30/2011 11:46 AM, Reza Rahman wrote:
> >> Linda,
> >>
> >> Overall, this looks good and is a timely change (I do have some
> >>concerns though). Detailed feedback below:
> >>
> >> * ISSUE 1: Should we support the use of annotations for resource
> >>configuration (in addition to DataSourceDefinition) or
> >> should we require that resource configurability metadata be specified
> >>in XML?
> >> - The annotations should definitely be supported. Although a majority
> >>of production applications are unlikely to use
> >> annotations for resource configuration, they are very valuable for RoR
> >>style RAD development and minimizing XML.
> >>
> >> * ISSUE 2: If we support the use of annotations, which of the above
> >>approaches should we take -- resource-specific or
> >> generic?
> >> - The generic annotation approach is very tempting, but does have some
> >>significant problems. Besides being less
> >> type-safe, they are also not very self-contained/self-documenting and
> >>hence much less usable. They could have been
> >> workable if the different resource types had more in common, but they
> >>really don't (besides some superficial
> >> similarities in properly names). I think we should avoid the generic
> >>annotation approach or reserve it for cases where
> >> containers use them to allow for configuring resources outside the
> >>common types. If we do have a generic annotation for
> >> edge cases, it is probably best to coordinate with an active JCA EG on
> >>that annotation since most if not all resources
> >> configured this way are likely to be JCA resources.
> >>
> >> * ISSUE 3: How should we name the standard properties? Do they require
> >>a "package"-specific prefix?
> >> - If we retain the generic annotation approach for provider-specific
> >>edge cases, we should recommend that properties use
> >> sensible "package"-specific prefixes. The issue is that although
> >>property names might be similar, their meaning and
> >> usage patterns would likely be very different depending on the actual
> >>resource type, so they should be categorized and
> >> documented separately.
> >>
> >> * ISSUE 4: If we take a generic approach, should we use this for
> >>DataSourceDefinition as well, treating the existing
> >> DataSourceDefinition annotation and XML as "legacy"?
> >> - I think it was done right in Java EE 6 in the first place. For
> >>example, Resin has always had cleanly separated XML
> >> tags for database, JMS, etc resource configuration.
> >>
> >> * ISSUE 5: Which XML format should we use? Resource-specific or generic?
> >> - Resource specific for "well known" resources and generic for the
> >>others that would be provider specific with some
> >> usage guidelines.
> >>
> >> * ISSUE 6: Should we support the use of annotations for the
> >>specification of per-tenant reconfigurability?
> >> - As you know, I (and others) expressed concerns around cloud support
> >>in the past. I think this issue crystallizes some
> >> of those concerns. What I see as largely an edge case (multi-tenant
> >>Java EE applications that require a tenant-specific
> >> override) would complicate a far more mundane/common use case
> >>(deploying a resource in a vanilla Java EE application). I
> >> think we should reconsider if this particular cloud feature is really
> >>needed. If it is not, we could avoid this bit of
> >> complexity altogether. Multi-tenant enabled application developers
> >>would simply have to let deployers know what
> >> resources need to be overriden via more traditional forms of
> >>documentation without any container intervention (something
> >> they would likely need to do anyway). If we still think this is
> >>something that is really needed, it should be supported
> >> in annotations as well as XML. Having something in XML and not in
> >>annotations (or vice versa) is likely to be confusing.
> >>
> >> * ISSUE 7: If we support the use of annotations for the specification
> >>of per-tenant reconfigurability, which approach
> >> should we take.
> >> - If this feature is indeed needed, I think using resource-specific
> >>annotations with separate typed elements is the
> >> least worst. It is the most type-safe and self-documenting, but it will
> >>cause annotation bloat. All these options cause
> >> additional complexity for resource configuration in non-cloud
> >>applications. I could not think of an alternate way that
> >> avoids the complexity while still supporting this feature.
> >>
> >> * ISSUE 8: Which approach should we take for the specification of
> >>per-tenant reconfigurability using XML: type-specific
> >> XML elements or generic resource-definition elements?
> >> - As stated above, type-specific elements are far more
> >>readable/self-documenting and less verbose (even more so in XML
> >> than in annotations).
> >>
> >> ISSUE 9: Should resource configuration definitions be embedded in the
> >>existing descriptors or should there be a separate
> >> XML descriptor?
> >> - I think the decision in Java EE 6 to utilize the existing descriptors
> >>is the correct one. It avoids adding yet another
> >> Java EE deployment descriptor instead of just putting resource
> >>definitions in application.xml, web.xml, beans.xml, etc.
> >> Resin has done application-specific resource deployment for ages and
> >>we've never seen a need to create a separate
> >> descriptor for resources. Similarly, Spring allows for resource
> >>definition in it's application context descriptors. I
> >> think creating a separate descriptor adds little value and goes against
> >>the norm for server-side Java development.
> >>
> >> Hope this makes sense.
> >>
> >> Cheers,
> >> Reza
> >>
> >>
> >> On 8/26/2011 11:34 AM, Reza Rahman wrote:
> >>> Linda,
> >>>
> >>> Hmm - for some reason I did not get your original email? I'm a bit
> >>>tied up at the moment but will try to get you
> >>> detailed feedback by next week at the latest...
> >>>
> >>> Cheers,
> >>> Reza
> >>>
> >>>
> >>> On 8/26/2011 5:36 AM, Werner Keil wrote:
> >>>> Linda/all,
> >>>>
> >>>> Thanks a lot for the suggestions.
> >>>>
> >>>> I highly appreciate some of these items, especially JMS which I saw
> >>>>recently in a project can be a beast hard to
> >>>> tame. In fact, based on Oracle's (pre EE6) own technologies combined
> >>>>with some Spring which caused many issues, not
> >>>> only due to lack of understanding how to use it properly.
> >>>>
> >>>> I'll try to look into those, probably gather feedback from people who
> >>>>deal with this and reply here, particularly for
> >>>> the JMS Use Case, although it may not be the only one. Is this
> >>>>coordinated with JMS 2.0 btw, e.g. by having the Spec
> >>>> Lead on this list?
> >>>>
> >>>> Regards,
> >>>> Werner
> >>>>
> >>>> On Fri, Aug 26, 2011 at 3:13 AM, Linda DeMichiel
> >>>><linda.demichiel_at_oracle.com <mailto:linda.demichiel_at_oracle.com>>
> wrote:
> >>>>
> >>>> Aside from Reza's email (thanks, Reza!), we haven't received much
> >>>> feedback on the resource configuration front. Under the assumption
> >>>> that silence implies consent, we'd like to move on to the next
> >>>>steps
> >>>> in this direction.
> >>>>
> >>>> This email contains a number of items that require your input.
> >>>> Briefly, we need feedback on the following aspects:
> >>>>
> >>>> 1. The use of annotations for resource configuration.
> >>>> 2. The form that such annotations (if supported) should take.
> >>>> 3. The form of XML elements for resource configuration.
> >>>> 4. How metadata related to per-tenant (re)configurability should
> >>>>be
> >>>> specified.
> >>>> 5. Whether the XML elements should be embedded in the current
> >>>>descriptors
> >>>> or there should be a separate descriptor.
> >>>>
> >>>> These items are discussed further in the message below. I have
> >>>> flagged specific items on which we need your feedback as "ISSUE:"
> >>>>
> >>>> Since the decision on how to specify metadata for
> >>>>reconfigurability
> >>>> may likely impact the decision on the format to use to specify
> >>>> annotations and XML for resource configuration, I recommend that
> >>>>you
> >>>> make 2 passes to work through this:
> >>>> (1) to review the options and how they interact;
> >>>> (2) to provide your opinions on the issues.
> >>>>
> >>>> thanks,
> >>>>
> >>>> -Linda
> >>>>
> >>>> ---------------------------
> >>>>
> >>>> 1. Annotations for resource configuration
> >>>>
> >>>> Java EE 6 currently supports use of the DataSourceDefinition
> >>>>annotation.
> >>>> This annotation is defined as follows:
> >>>>
> >>>> package javax.annotation.sql;
> >>>>
> >>>> @Retention(RUNTIME)
> >>>> @Target({TYPE})
> >>>> public @interface DataSourceDefinition {
> >>>> String name();
> >>>> String className();
> >>>> String description() default "";
> >>>> String url() default "";
> >>>> String user() default "";
> >>>> String password() default "";
> >>>> String databaseName() default "";
> >>>> int portNumber() default -1;
> >>>> String serverName() default "localhost";
> >>>> int isolationLevel() default -1;
> >>>> boolean transactional() default true;
> >>>> int initialPoolSize() default -1;
> >>>> int maxPoolSize() default -1;
> >>>> int minPoolSize() default -1;
> >>>> int maxIdleTime() default -1;
> >>>> int maxStatements() default -1;
> >>>> String[] properties() default {};
> >>>> int loginTimeout() default 0;
> >>>> }
> >>>>
> >>>>
> >>>> Following this pattern, we might define similar annotations for
> >>>>the other
> >>>> standard resource types -- e.g., define JMSConnectionFactory,
> >>>>JMSDestination,
> >>>> MailSession, and ConnectorResource annotations.
> >>>>
> >>>>
> >>>> An alternative is to take a more generic approach, and instead of
> >>>> these support a generic ResourceDefinition annotation:
> >>>>
> >>>> package javax.annotation.resource;
> >>>>
> >>>> @Retention(RUNTIME)
> >>>> @Target({TYPE})
> >>>> public @interface ResourceDefinition {
> >>>> String description() default "";
> >>>> String name();
> >>>> String className();
> >>>> String[] properties() default {};
> >>>> }
> >>>>
> >>>> With the generic ResourceDefinition approach, all
> >>>>resource-specific
> >>>> information would be provided as properties. For that reason, the
> >>>>generic
> >>>> approach relies heavily on the use of strings and therefore has
> >>>>less
> >>>> type safety. We would need to standardize on the property names
> >>>>to be
> >>>> used, and we would also need to decide whether to require a
> >>>> package-specific prefix on the property names (as illustrated in
> >>>>the
> >>>> examples below) to distinguish them from vendor properties.
> >>>>
> >>>>
> >>>> Examples:
> >>>>
> >>>> Example 1: data sources
> >>>>
> >>>> @DataSourceDefinition(
> >>>> name="java:app/MyDataSource",
> >>>> className="com.foobar.MyDataSource",
> >>>> portNumber=6689,
> >>>> serverName="myserver.com <http://myserver.com>",
> >>>> user="lance",
> >>>> password="secret"
> >>>> )
> >>>>
> >>>> vs
> >>>>
> >>>> @ResourceDefinition(
> >>>> name="java:app/MyDataSource",
> >>>> className="com.foobar.MyDataSource",
> >>>> properties={
> >>>> "javax.sql.portNumber=6689",
> >>>> "javax.sql.serverName=myserver.com <http://myserver.com>",
> >>>> "javax.sql.user=lance",
> >>>> "javax.sql.password=secret"
> >>>> }
> >>>> )
> >>>>
> >>>>
> >>>> Example 2: JMS connection factories
> >>>>
> >>>> @JMSConnectionFactory(
> >>>> name="java:app/MyJMSFactory",
> >>>> resourceType="javax.jms.QueueConnectionFactory",
> >>>> clientId="foo",
> >>>> connectionTimeout=10,
> >>>> initialPoolSize=5,
> >>>> maxPoolSize=15
> >>>> )
> >>>>
> >>>> vs
> >>>>
> >>>> @ResourceDefinition(
> >>>> name="java:app/MyJMSFactory",
> >>>> className="javax.jms.QueueConnectionFactory",
> >>>> properties={
> >>>> "javax.jms.clientId=foo",
> >>>> "javax.jms.connectionTimeout=10",
> >>>> "javax.jms.initialPoolSize=5",
> >>>> "javax.jms.maxPoolSize=15"
> >>>> }
> >>>> )
> >>>>
> >>>>
> >>>> Example 3: JMS destinations
> >>>>
> >>>> @JMSDestination(
> >>>> name="java:app/MyQueue",
> >>>> resourceType="javax.jms.Queue",
> >>>> resourceName="queue124"
> >>>> )
> >>>>
> >>>> vs
> >>>>
> >>>> @ResourceDefinition(
> >>>> name="java:app/MyQueue",
> >>>> className="javax.jms.Queue",
> >>>> properties={
> >>>> "javax.jms.resourceName=queue124"
> >>>> }
> >>>> )
> >>>>
> >>>>
> >>>> ISSUE 1: Should we support the use of annotations for resource
> >>>>configuration
> >>>> (in addition to DataSourceDefinition) or should we require that
> >>>>resource
> >>>> configurability metadata be specified in XML?
> >>>>
> >>>> ISSUE 2: If we support the use of annotations, which of the above
> >>>> approaches should we take -- resource-specific or generic?
> >>>>
> >>>> ISSUE 3: How should we name the standard properties? Do they
> >>>>require
> >>>> a "package"-specific prefix?
> >>>>
> >>>> ISSUE 4: If we take a generic approach, should we use this for
> >>>> DataSourceDefinition as well, treating the existing
> >>>>DataSourceDefinition
> >>>> annotation and XML as "legacy"?
> >>>>
> >>>>
> >>>> ------------------
> >>>>
> >>>>
> >>>> 2. XML for resource configuration
> >>>>
> >>>> We currently support the use of the data-source element in the
> >>>>Java EE 6
> >>>> descriptors as part of the jndiEnvironmentRefsGroup type. (See
> >>>> http://java.sun.com/xml/ns/javaee/javaee_6.xsd for the details..)
> >>>>
> >>>> For the new elements, the choices are again whether to have
> >>>>elements
> >>>> that are resource-specific or generic.
> >>>>
> >>>>
> >>>> Example:
> >>>>
> >>>> Resource-specific approach, JMS connection factory:
> >>>>
> >>>> <jms-connection-factory>
> >>>> <name>MyJMSFactory</name>
> >>>> <resource-type>javax.jms.QueueConnectionFactory</resource-type>
> >>>> <client-id>foo</client-id>
> >>>> <connection-timeout>10</connection-timeout>
> >>>> <initial-pool-size>5</initial-pool-size>
> >>>> <max-pool-size>15</max-pool-size>
> >>>> </jms-connection-factory>
> >>>>
> >>>>
> >>>> Generic approach:
> >>>>
> >>>> <resource-definition>
> >>>> <name>MyJMSFactory</name>
> >>>> <resource-type>javax.jms.QueueConnectionFactory</resource-type>
> >>>> <property>
> >>>> <name>clientId</name>
> >>>> <value>foo</value>
> >>>> </property>
> >>>> <property>
> >>>> <name>connectionTimeout</name>
> >>>> <value>10</value>
> >>>> </property>
> >>>> <property>
> >>>> <name>initialPoolSize</name>
> >>>> <value>5</value>
> >>>> </property>
> >>>> <property>
> >>>> <name>maxPoolSize</name>
> >>>> <value>15</value>
> >>>> </property>
> >>>> </resource-definition>
> >>>>
> >>>>
> >>>> Note that the specification of properties could be made somewhat
> >>>>less
> >>>> verbose by the use of attributes. The example above uses elements
> >>>> to be more consistent with the current style of our deployment
> >>>> descriptors.
> >>>>
> >>>>
> >>>> With XML, we again have the issue as to whether properties in the
> >>>> generic approach should use a resource-specific prefix, e.g.,
> >>>>
> >>>> <resource-definition>
> >>>> <name>MyJMSFactory</name>
> >>>> <resource-type>javax.jms.QueueConnectionFactory</resource-type>
> >>>> <property>
> >>>> <name>javax.jms.clientId</name>
> >>>> <value>foo</value>
> >>>> </property>
> >>>> <property>
> >>>> <name>javax.jms.connectionTimeout</name>
> >>>> <value>10</value>
> >>>> </property>
> >>>> <property>
> >>>> <name>javax.jms.initialPoolSize</name>
> >>>> <value>5</value>
> >>>> </property>
> >>>> <property>
> >>>> <name>javax.jms.maxPoolSize</name>
> >>>> <value>15</value>
> >>>> </property>
> >>>> </resource-definition>
> >>>>
> >>>>
> >>>> ISSUE 5: Which XML format should we use? Resource-specific or
> >>>>generic ?
> >>>>
> >>>>
> >>>> ----------------------------
> >>>>
> >>>>
> >>>> 3. Specification of per-tenant reconfigurability
> >>>>
> >>>> In the resource configuration document that I circulated several
> >>>>weeks
> >>>> ago, I noted that we needed a means to include information about
> >>>>which
> >>>> attributes of a resource definition must be modified by a tenant,
> >>>>which
> >>>> must not be modified, and which may be modified.
> >>>>
> >>>> The remainder of this message outlines how that might be handled
> >>>>in
> >>>> the various approaches.
> >>>>
> >>>> If we take a generic approach (@ResourceDefinition), the property
> >>>>elements
> >>>> could be expanded to specify a configurability element. For
> >>>>example:
> >>>>
> >>>> @Retention(RUNTIME)
> >>>> @Target({TYPE})
> >>>> public @interface ResourceDefinition {
> >>>> String description() default "";
> >>>> String name();
> >>>> String className();
> >>>> ConfigProperty[] configProperties() default {};
> >>>> }
> >>>>
> >>>> @Retention(RUNTIME)
> >>>> @Target({})
> >>>> public @interface ConfigProperty {
> >>>> String name();
> >>>> String value();
> >>>> Configurability configurability() default
> >>>>Configurability.MAY_MODIFY;
> >>>> }
> >>>>
> >>>> public enum Configurability {
> >>>> MUST_MODIFY,
> >>>> MUST_NOT_MODIFY,
> >>>> MAY_MODIFY,
> >>>> }
> >>>>
> >>>>
> >>>>
> >>>> Example:
> >>>>
> >>>> @ResourceDefinition(
> >>>> name="java:app/MyJMSFactory",
> >>>> className="javax.jms.QueueConnectionFactory",
> >>>> configProperties={
> >>>> @ConfigProperty(
> >>>> name="clientId",
> >>>> value="foo",
> >>>> configurability=MUST_MODIFY),
> >>>> @ConfigProperty(
> >>>> name="connectionTimeout",
> >>>> value="10"),
> >>>> @ConfigProperty(
> >>>> name="initialPoolSize",
> >>>> value="5"),
> >>>> @ConfigProperty(
> >>>> name="maxPoolSize",
> >>>> value="15")
> >>>> }
> >>>> )
> >>>>
> >>>>
> >>>> A possible alternative to the use of the embedded @ConfigProperty
> >>>> annotation approach might be to embed further syntax into the
> >>>>property
> >>>> specification to capture configurabilty semantics. For example:
> >>>>
> >>>> @ResourceDefinition(
> >>>> name="java:app/MyJMSFactory",
> >>>> className="javax.jms.QueueConnectionFactory",
> >>>> properties={
> >>>> "javax.jms.clientId=foo", // must modify
> >>>> "javax.jms.connectionTimeout=?10", // may modify
> >>>> "javax.jms.transactional==true" // must not modify
> >>>> }
> >>>> )
> >>>>
> >>>>
> >>>>
> >>>> Things get more complicated with the typed resource definition
> >>>> approach. Consider what happens to JMSConnectionFactory, where
> >>>>some
> >>>> of the non-property elements are optional.
> >>>>
> >>>> Maintaining typing using the separate elements approach leads to
> >>>> a proliferation of annotations.
> >>>>
> >>>> For example:
> >>>>
> >>>> @JMSConnectionFactory(
> >>>> name="java:app/MyJMSFactory",
> >>>> resourceType="javax.jms.QueueConnectionFactory",
> >>>> clientId=_at_ClientId(value="foo",
> >>>> configurability=Configurability.MUST_MODIFY),
> >>>> connectionTimeout=_at_ConnectionTimeout(10),
> >>>> initialPoolSize=_at_PoolSize(5),
> >>>> maxPoolSize=_at_PoolSize(15)
> >>>> )
> >>>>
> >>>>
> >>>> An alternative is that only string-valued elements are used, and
> >>>>all
> >>>> elements are of type ResourceElement:
> >>>>
> >>>> @Retention(RUNTIME) @Target({})
> >>>> public @interface ResourceElement {
> >>>> String value();
> >>>> Configurability configurability() default
> >>>>Configurability.MAY_MODIFY;
> >>>> }
> >>>>
> >>>>
> >>>> Example:
> >>>>
> >>>> @JMSConnectionFactory(
> >>>> name="java:app/MyJMSFactory",
> >>>> resourceType="javax.jms.QueueConnectionFactory",
> >>>> clientId=_at_ResourceElement(value="foo",
> >>>>configurability=MUST_MODIFY),
> >>>> connectionTimeout=_at_ResourceElement("10"),
> >>>> initialPoolSize=_at_ResourceElement("5"),
> >>>> maxPoolSize=_at_ResourceElement("15")
> >>>> )
> >>>>
> >>>>
> >>>> ISSUE 6: Should we support the use of annotations for the
> >>>>specification
> >>>> of per-tenant reconfigurability?
> >>>>
> >>>> ISSUE 7: If we support the use of annotations for the
> >>>>specification of
> >>>> per-tenant reconfigurability, which approach should we take:
> >>>> (1) Generic ResourceDefinition annotation
> >>>> (2) Resource-specific annotations, using separate typed elements
> >>>> (3) Resource-specific annotations, using ResourceElement approach
> >>>> (4) Other?
> >>>>
> >>>>
> >>>> ---------------------------
> >>>>
> >>>>
> >>>> 4. Specification of per-tenant reconfigurability using XML
> >>>>
> >>>> With XML on the other hand, extension is fairly straightforward.
> >>>>The
> >>>> various types could be augmented with attributes.
> >>>>
> >>>>
> >>>> Example:
> >>>>
> >>>> <jms-connection-factory>
> >>>> <name configurability=MUST_NOT_MODIFY>java:app/MyJMSFactory</name>
> >>>> <resource-type configurability=MUST_NOT_MODIFY>
> >>>> javax.jms.QueueConnectionFactory
> >>>> </resource-type>
> >>>> <client-id configurability=MUST_MODIFY>foo</client-id>
> >>>> <connection-timeout>10</connection-timeout>
> >>>> <initial-pool-size>5</initial-pool-size>
> >>>> <max-pool-size>15</max-pool-size>
> >>>> </jms-connection-factory>
> >>>>
> >>>>
> >>>>
> >>>> With the generic approach, this would look as follows, assuming
> >>>> again a default of MAY_MODIFY if no attribute is specified:
> >>>>
> >>>> <resource-definition>
> >>>> <name configurability=MUST_NOT_MODIFY>java:app/MyJMSFactory</name>
> >>>> <resource-type configurability=MUST_NOT_MODIFY>
> >>>> javax.jms.QueueConnectionFactory
> >>>> </resource-type>
> >>>> <property configurability=MUST_MODIFY>
> >>>> <name>clientId</name>
> >>>> <value>foo</value>
> >>>> </property>
> >>>> <property>
> >>>> <name>connectionTimeout</name>
> >>>> <value>10</value>
> >>>> </property>
> >>>> <property>
> >>>> <name>initialPoolSize</name>
> >>>> <value>5</value>
> >>>> </property>
> >>>> <property>
> >>>> <name>maxPoolSize</name>
> >>>> <value>15</value>
> >>>> </property>
> >>>> </resource-definition>
> >>>>
> >>>>
> >>>> ISSUE 8: Which approach should we take for the specification of
> >>>> per-tenant reconfigurability using XML: type-specific XML elements
> >>>> or generic resource-definition elements?
> >>>>
> >>>>
> >>>> ---------------------------------------
> >>>>
> >>>> 5. XML Descriptors for the specification of resource
> >>>>configuration.
> >>>>
> >>>> A further item pertains to where the XML elements for resource
> >>>> configuration should be located -- i.e., in the existing Java EE
> >>>> descriptors, or in a separate resources.xml (or services.xml)
> >>>> descriptor. In our view, the fact that these resource
> >>>>configuration
> >>>> elements are applicable to the application as a whole argues that
> >>>>there
> >>>> should be a separate descriptor.
> >>>>
> >>>> ISSUE 9: Should resource configuration definitions be embedded in
> >>>> the existing descriptors or should there be a separate XML
> >>>>descriptor?
> >>>>
> >>>> ---------------------------
> >>>>
> >>>>
> >>>> RECAP OF THE ISSUES. ALL OF THESE NEED YOUR INPUT:
> >>>>
> >>>>
> >>>> ISSUE 1: Should we support the use of annotations for resource
> >>>>configuration
> >>>> (in addition to DataSourceDefinition) or should we require that
> >>>>resource
> >>>> configurability metadata be specified in XML?
> >>>>
> >>>> ISSUE 2: If we support the use of annotation, which of the above
> >>>> approaches should we take -- resource-specific or generic?
> >>>>
> >>>> ISSUE 3: How should we name the standard properties? Do they
> >>>>require
> >>>> a "package"-specific prefix?
> >>>>
> >>>> ISSUE 4: If we take a generic approach, should we use this for
> >>>> DataSourceDefinition as well, treating the existing
> >>>>DataSourceDefinition
> >>>> annotation and XML as "legacy"?
> >>>>
> >>>> ISSUE 5: Which XML format should we use? Resource-specific or
> >>>>generic ?
> >>>>
> >>>> ISSUE 6: Should we support the use of annotations for the
> >>>>specification
> >>>> of per-tenant reconfigurability?
> >>>>
> >>>> ISSUE 7: If we support the use of annotations for the
> >>>>specification of
> >>>> per-tenant reconfigurability, which approach should we take:
> >>>> (1) Generic ResourceDefinition annotation
> >>>> (2) Resource-specific annotations, using separate typed elements
> >>>> (3) Resource-specific annotations, using ResourceElement approach
> >>>> (4) Other?
> >>>>
> >>>> ISSUE 8: Which approach should we take for the specification of
> >>>> per-tenant reconfigurability using XML: type-specific XML elements
> >>>> or generic resource-definition elements?
> >>>>
> >>>> ISSUE 9: Should resource configuration definitions be embedded in
> >>>> the existing descriptors or should there be a separate XML
> >>>>descriptor?
> >>>>
> >>>> --------
> >>>>
> >>>> Thanks in advance for your feedback!
> >>>>
> >>>> -Linda
> >>>>
> >>>>
> >>>>
> >>>>-----------------------------------------------------------------------
> >>>>-------------------------------------------------
> >>>>
> >>>> No virus found in this message.
> >>>> Checked by AVG - www.avg.com <http://www.avg.com>
> >>>> Version: 10.0.1392 / Virus Database: 1520/3855 - Release Date:
> >>>>08/24/11
> >>>>
> >>>
> >>
>
>
>