Skip to main content

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

  • From: Bill Shannon <bill.shannon@...>
  • To: David Blevins <david.blevins@...>
  • Cc: jsr342-experts@...
  • Subject: [javaee-spec users] [jsr342-experts] Re: platform default DataSource and JMS ConnectionFactory
  • Date: Mon, 02 Apr 2012 12:04:55 -0700
  • List-id: <jsr342-experts.javaee-spec.java.net>

"If a tree falls in the forest and no one is there to see it, does it
make a sound?"

I think it's fine if you don't create the resource as long as the app
can't tell that you didn't create the resource.  The only place I can
see that being an issue is if the application declares no DataSource
resource references but does a JNDI lookup for the default DataSource.
I would expect that to succeed, as it does for all other pre-defined
resources.

David Blevins wrote on 03/29/12 16:29:
Thanks for the follow up, Bill.

If the user has not explicitly added any datasources, I can see this proposal 
working fine and matches current behavior.

We currently will create a default datasource, called "Default DataSource", if the app needs 
one and the user has not configured any datasources.  Calling that 
"java:comp/defaultDataSource" is an easy and welcome addition.  We will not create a default 
datasource if the application does not have any<resource-ref>  or @Resource refs to a DataSource. 
 Same for ConnectionFactory.

If the user has explicitly configured a datasource, adding a default 
datasource makes no sense.

If we're willing to state in the specification that default resources are not 
created if they are not needed, everything should be fine.

We can simply say, "If the application requires an X and has not configured one, a 
default X is created bound to java:comp/defaultX and used to satisfy all references 
requiring an X"


-David


On Mar 29, 2012, at 3:27 PM, Bill Shannon wrote:

I agree with many of your comments about #2, although note that we already
expect users to understand that they have to map their resource references
to resources provided by the platform - that's been part of the Java EE
model from the beginning.  What #2 does is give them a standard way to do
this thing that they're already expected to know that they have to do.

The advantage of #1 is that you no longer need to know that you have to do
that, at least at the beginning and for many simple applications.

Right now the spec defines it as an error if you deploy an application
where the resource references haven't been mapped to resources provided
by the server.  What you seem to have done with OpenEJB/TomEE is to
redefine that error case to behave differently.  Clearly you recognized
the same problem we did and solved it in a product-specific way instead
of enhancing the standard.  The clear risk with that is that you might
conflict with future enhancements to the standard.  No doubt you can find
a product-specific way to address this conflict.

I think we can also define this new capability in a way that would
reduce the conflict.  For example, if we only require that the server
provide a way to set this default, and that if the default is set the
specified default mapping behavior occurs, that would allow your users
to unset the default data source or connection factory and fall back
to your product-specific behavior.  (Although we should probably
discuss whether the behavior you describe is a violation of the spec
requirement to fail deployment in this case, and whether the spec
specifies this requirement clearly.)


David Blevins wrote on 03/24/2012 04:38 PM:
I'm struggling with this one a bit.

Any user is one @DataSourceDefinition(name = 
"java:comp/env/defaultDataSource") annotation away from portable bliss.

It's hard to imagine any sort of spec definition that is simpler.

What I can't figure out:

With approach #2, requiring 'lookup=java:comp/DefaultDataSource', seems to 
defeat the point.  Having to take an explicit action isn't really a default.  
New users will not know to do it and that will lead us right back to #1.  If 
they are going to have to learn to do something, learning to use 
@DataSourceDefinition is the better thing to teach/learn.  As well if you 
just want to be lazy, having to be _explicitly_ lazy kind of defeats the 
purpose :)

If the goal is solving default datasources, #2 does not solve a "@Resource DataSource dataSource" 
reference, in which case I don't see the value in the complexity especially if it in any way might lead 
some new user to believe (correctly or incorrectly) that a true default DataSource reference 
("@Resource DataSource dataSource") is portably the same as the proposed 
"java:comp/env/defaultDataSource".  That's going to be a tough one to have to explain over and 
over again.

With #1, where the reference is truly unqualified, I struggle with how this 
reconciles with vendor specific config, which can include defaults.  The 
below refers to OpenEJB/TomEE.

For example, if a user has configured in the server two DataSources, "orange" and 
"green", these @Resource references will map as one might think:

     @Resource(name="orange")
     DataSource ds1;

     @Resource(name="green")
     DataSource ds2;

With this a spec standard that involved #1, it would seem both these 
datasource would now have to map to the platform default DataSource.

In our minds, defining those resources with those names is explicit action 
enough.  There's really no way we could change that without breaking nearly 
every app.

And for the sake of full transparency, this works too:

     @Resource
     DataSource orange;

     @Resource
     DataSource green;

The order of what wins is essentially:

   1. lookup
   3. name (exact)
   4. name (fuzzy)

For "fuzzy", we just start chopping off name components starting on the left.  Given the spec defined default JNDI 
binding is "java:comp/org.acme.Foo/orange" , we first check "comp/org.acme.Foo/orange", then 
"org.acme.Foo/orange", then finally "orange".

And of course all this magic can be disabled for production, so if the user 
doesn't take explicit action to configure something via lookup, mappedName, 
or an xml file bundled with the app, we can fail deployment.

The above applies to all @Resource resolution, so that includes 
ConnectionFactory, Topic, Queue, etc.

I'm open to ideas, but can't seem to figure out how to make a #1 approach 
work with regards to vendor config and a #2 approach seems to oddly encourage 
people to be explicitly implicit while also misleading and confusing how 
defaults actually work and which syntax is portable.


-David


On Mar 12, 2012, at 11:33 AM, 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.








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

Bill Shannon 04/02/2012

<Possible follow-up(s)>

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

Bill Shannon 04/02/2012

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

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