Hi Linda/all,
if I remember this right, #3 a combination with a default JNDI entry
(jdbc/__default) and a pre-configured data source already is the
default behavior with embedded GlassFish for JPA applications. (more
here:
http://docs.oracle.com/cd/E18930_01/html/821-2424/gksmw.html)
I think this was intended to have a very convenient way of testing JPA
based applications.
So to me #1 clearly isn't enough. This is a little too much magic
going on and I second every disadvantage you listed.
Additionally I like to point out, that we always should offer a way to
control automatic behavior. I tend to require at least #2 and allow
#3 (and leave the rest to the vendors).
-Markus
On 12 March 2012 19: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.
>
> 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.
>
>