Skip to main content

[jsr342-experts] Re: [javaee-spec users] platform default DataSource and JMS ConnectionFactory

  • From: Adam Bien <abien@...>
  • To: jsr342-experts@...
  • Subject: [jsr342-experts] Re: [javaee-spec users] platform default DataSource and JMS ConnectionFactory
  • Date: Sun, 15 Apr 2012 19:11:55 +0200

+1. And I would even supply default producers. E.g. If there is only one 
persistence-unit specified, it should be possible to inject it with @Inject.



On 22.03.2012, at 22:45, 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 :
> 
> @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@...> 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@...> 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
> 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 | Twitter | Blog | LinkedIn | Paris JUG



[jsr342-experts] Re: [javaee-spec users] platform default DataSource and JMS ConnectionFactory

Adam Bien 04/15/2012
 
 
Close
loading
Please Confirm
Close