I like the idea of #3 and use one of the new JNDI locations defined in Java
EE 6, module perhaps so other apps in the same EAR could share the
datasource.
As we'll more than likely have an XML counterpart for this, might I
recommend having one file for all this configuration stuff? We already have
ejb.xml, application.xml, beans.xml (yes, I know this is as much of a
marker file for the archives as anything else), web.xml, faces-config.xml,
persistence.xml and possibly one or two I've forgotten. I also understand
some of these are optional now like web.xml or faces-config.xml. Moving
towards a unification of configuration files which would allow
configuration of all (most only possible?) of these would be a great help
for new developers.
On Mon, Mar 12, 2012 at 12:33, Linda DeMichiel
<linda.demichiel_at_oracle.com>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<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.
>
>
>
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu