[javaee-spec users] [jsr342-experts] Re: platform default DataSource and JMS ConnectionFactory
- From: David Blevins <david.blevins@...>
- To: jsr342-experts@...
- Subject: [javaee-spec users] [jsr342-experts] Re: platform default DataSource and JMS ConnectionFactory
- Date: Sat, 24 Mar 2012 16:38:50 -0700
- List-id: <jsr342-experts.javaee-spec.java.net>
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
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:
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
And for the sake of full transparency, this works too:
The order of what wins is essentially:
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.
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:
> 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:
> 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.