Skip to main content

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

  • From: Werner Keil <werner.keil@...>
  • To: jsr342-experts@...
  • Cc: reza_rahman@...
  • Subject: [javaee-spec users] [jsr342-experts] Re: platform default DataSource and JMS ConnectionFactory
  • Date: Fri, 23 Mar 2012 00:06:50 +0100
  • List-id: <jsr342-experts.javaee-spec.java.net>

+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@...> 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 | TwitterBlog | LinkedInParis JUG



--

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"



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

(continued)

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

Bill Shannon 03/14/2012

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

Jason Porter 03/15/2012

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

Bill Shannon 03/15/2012

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

Markus Eisele 03/13/2012

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

Florent BENOIT 03/13/2012

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

Linda DeMichiel 03/14/2012

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

Reza Rahman 03/15/2012

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

Werner Keil 03/15/2012

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

Antonio Goncalves 03/22/2012

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

Reza Rahman 03/22/2012

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

Werner Keil 03/22/2012

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

David Blevins 03/24/2012

Message not available

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

David Blevins 03/29/2012
 
 
Close
loading
Please Confirm
Close