+1
That sounds even more easy and readable. If it's doable for EE7 we should
do it.
On Thu, Mar 22, 2012 at 10:45 PM, Antonio Goncalves <
antonio.goncalves_at_gmail.com> wrote:
> 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>
>
--
Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead
Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR
Skype werner.keil | Google+ gplus.to/wernerkeil
* TUGDK: Mar 29 2012, Copenhagen, Denmark. Werner Keil, JCP EC Member,
Java Social
Co-Spec Lead will talk about "Social Media"
* 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"