Hi,
I like #2... but I would also go further : what about *producing* a
default Datasource, JMSConnectionFactory, Queue, Topic with CDI producers ?
It would be great if a EE 7 app server would automatically produce these
resources. As a developer I could go :
@Inject
DataSource myDS;
If there is more than one, CDI will tell me it's ambiguous and then I could
go :
@Resource(name="myDataSource", lookup="java:comp/**defaultDataSource")
DataSource myDS;
Or, staying with CDI, what about having a specified qualifier for these
kind of default resources which will be produced by the container ?
Something like :
@Inject @DefaultResource
DataSource myDS;
@Inject @DefaultResource
Topic myTopic;
This way there's no more ambiguous dependecy.
My 2 cents
Antonio
On Thu, Mar 15, 2012 at 19:33, Werner Keil <werner.keil_at_gmail.com> wrote:
> 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"
>
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
Blog <http://feeds.feedburner.com/AntonioGoncalves> |
LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
JUG <http://www.parisjug.org>