On 3/22/2012 5:45 PM, Antonio Goncalves 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 :
>
+1
> @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
> <mailto: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 <mailto: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.
>
> 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 <http://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
> <http://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>
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2012.0.1913 / Virus Database: 2114/4886 - Release Date: 03/22/12
>