While 2 may offer some flexibility (e.g. using a different part of the JNDI
tree, etc.) I find it a bit verbose and easier to make mistakes. Saw that
with plenty of projects where juggling with or without the "java:comp..."
wa always a challenge.
From an ease of use point of view I prefer #1
On Thu, Mar 15, 2012 at 7:23 PM, Reza Rahman <reza_rahman_at_lycos.com> wrote:
> I like approach #2.
>
>
> On 3/12/2012 2:33 PM, Linda DeMichiel wrote:
>
>> The Java EE platform requires that a platform product provide both a
>> database as well as a JMS provider in the operational environment.
>>
>> We've gotten a number of requests that the Java EE platform therefore
>> define both a default data source and a default JMS connection factory
>> to access these resources.
>>
>> The JMS spec lead has recently submitted a JIRA issue to us on behalf of
>> the
>> JMS Expert Group requesting such an enhancement:
>> http://java.net/jira/browse/**JAVAEE_SPEC-2<http://java.net/jira/browse/JAVAEE_SPEC-2>
>> .
>>
>> We agree that such default, preconfigured resources would facilitate
>> ease of development, and that they should be added to the platform.
>>
>> Assuming that the Expert Group agrees with us, we need your input
>> on how these resources should best be made accessible.
>>
>> We see two options. For the sake of simplification, I'll describe these
>> in terms of data sources, but we would expect to treat JMS connection
>> factories in the same way. The requirements for JMS would of course
>> only apply in environments in which JMS is required to be supported
>> (i.e., in the full Java EE platform, but not in the Web Profile).
>>
>> Approach (1): We require that if a DataSource resource isn't mapped to
>> a specific database, it is mapped to a preconfigured DataSource for
>> the product's default database. I.e., in the absence of any action on
>> the part of the deployer, the following will map to the product's
>> default database:
>>
>> @Resource(name="myDataSource")
>> DataSource myDS;
>>
>> In this approach, there is no special JNDI name and no way to specify
>> with the lookup element that this is the selected database.
>>
>>
>> Approach (2): We define a special JNDI name/location at which the
>> DataSource for the default database is made available, e.g.,
>> java:comp/defaultDataSource. [Names TBD.]
>>
>> The application specifies the binding of the resource reference to
>> this in the usual way, i.e., as follows:
>>
>> @Resource(name="myDataSource", lookup="java:comp/**defaultDataSource")
>> DataSource myDS;
>>
>> An advantage of approach (1) is that it is much simpler for beginning
>> developers since there is no special name that one needs to know.
>>
>> A disadvantage of approach (1) that it is harder to tell whether the
>> user made an error and forgot to map the data source reference, or
>> whether the user left it unmapped on purpose because they wanted it to
>> be automatically mapped to the default data source.
>>
>> An additional disadvantage of appraoch (1) is that if a different
>> lookup name is specified in @Resource, there is no name to replace it
>> with in the deployment descriptor to refer to the default data source.
>>
>> The disadvantage of approach (2) is that requiring a special JNDI
>> name be specified in the lookup element is more verbose.
>>
>> A possible third--"do both"--approach is that we define a well-known name,
>> but not require its use. This would result in the flexibility of
>> approach (2) with the terseness of approach (1), but would not make it
>> less error-prone.
>>
>> Please let us know your opinions on these issues.
>>
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.1913 / Virus Database: 2114/4872 - Release Date: 03/15/12
>>
>>
>>
>
--
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead
Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
Skype werner.keil | Google+ gplus.to/wernerkeil
* geecon: May 16 2012, Poznań, Poland. Werner Keil, JCP EC Member, Social
JSR Co-Spec Lead will present "Java EE 7"
* JustJava: May 19-20 2012, Sao Paulo, Brazil. Werner Keil, JCP EC
Member, Social
JSR Co-Spec Lead will present "Java Social"
* Dutch Mobile Conference: June 7-9 2012, Amsterdam, Netherlands. Werner
Keil, JCP EC (ME) Member, OpenDDR Evangelist will present "OpenDDR"