A reader wrote in asking about the right way to resolve JNDI resolution with JPA. In ejb-jar.xml and web.xml, you can set up resource-ref entries, and resolve them to "real" JNDI entries during the deployment stage. However, persistence.xml doesn't have an equivalent, nor does orm.xml, and ejb-jar.xml won't allow a resource reference all by itself, without being attached to a bean reference.
However, one of the things EJB3 offers is "configurationless EJB" -- where annotations are used to replace the entries in ejb-jar.xml.
Therefore, if you want your persistence unit to use a localized datasource name, like java:comp/env/jdbc/myDS, your options are rather limited: you can offer a mapping in an annotation (which is not a very good idea), or you can define your beans in ejb-jar.xml.
So: TSS readers, what's your take on the problem? How do you manage referring to datasources in persistence units?
Do you manually alter the persistence.xml on a per-deployment basis - or expect your deployer to?
Do you define a "configuration" EJB in ejb-jar.xml, just to find a way to resolve the resource-reference in deployment?
What's your opinion on the matter? Is it a problem at all?

We use Spring/Hibernate but the following might be transferrable to JEE.
We have separate /env(ironment) folders for dev, prod, acceptance testing, etc.
Our ant script copies in the right /env settings depending on the target environment.
We also have dataSource.xml and dataSource-junit.xml Spring config files which contain datasource definitions ONLY.
Loading up the data access layer from JUnit will reference dataSource-junit.xml and not dataSource.xml -- which references application server (JNDI) defined data sources.
It seems to works very well.
I think the key is that the connection details are not always tied to JNDI (i.e. dataSource-junit.xml), and that we can easily swap in dataSource-junit.xml vs dataSource.xml depending on if we're running the full app or testing.
The Ant script (effectively, our "Deployer"), takes care of making sure the right JNDI details are used depending on the target deployment environment, although typically the same JNDI ref is always used and details of the connection are configured within the app server.
From what I remember about J2EE (as opposed to JEE 5), the file that the beans were in did also contain JNDI references which is a problem.

Joseph's talking about EJB3 datasource lookups, not spring/hibernate stacks.
The best place to put datasource mapping is in the deployment descriptor for the app (server-specific). Typically you want your JEE server managing your connection pool and exposing it to the EJB app. After that simple named resource injection is straightforward:
<!-- in app-server descriptor, such as geronimo-application.xml -->
...expose registered datasource to app, mapping as myDs...
//in persistence.xml
myDs</jta-data-source
//Or in EJB directly (non-JPA)
@Resource DataSource myDs;
Then it is transportable across appservers by simply changing the deployment descriptor for the specific appserver (you don't need to alter JPA/EJB config or jars).

In my opinion, the real annoyance here is that the Java EE spec stack doesn't address how things get into the app-scoped JNDI context. I understand that there are a lot of different possible configurations that different appserver products may need to support, but it seems like there are some pretty common cases (global => app-scoped, for example) that should be included in the Java EE world, just so that the 80% case can be covered in a standard manner.
-Patrick
--
Patrick Linskey
http://bea.com

In my opinion, the real annoyance here is that the Java EE spec stack doesn't address how things get into the app-scoped JNDI context. I understand that there are a lot of different possible configurations that different appserver products may need to support, but it seems like there are some pretty common cases (global => app-scoped, for example) that should be included in the Java EE world, just so that the 80% case can be covered in a standard manner.

This is what has bothered me about Java EE for 7 years now. Total lack of addressability. So, Patrick, since we're in agreement on this can we focus on defining this for EE 6 instead of you blowing a lot of hot air over some esoteric JDO feature you want to add to JPA? ;-)
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

can we focus on defining this for EE 6 instead of you blowing a lot of hot air over some esoteric JDO feature you want to add to JPA?

For the benefit of the rest of us, does 1-N unidirectional FK relation count as esoteric ? or maybe identifying relationships is esoteric ? or perhaps that is being able to define indexes in the schema ? or maybe this esoteric feature is datastore transactions ? or could it be able to model Collection ? or have a Map with a join table ? or indexed Lists ? or ...
Damn, so much is esoteric these days ;-)

can we focus on defining this for EE 6 instead of you blowing a lot of hot air over some esoteric JDO feature you want to add to JPA?

For the benefit of the rest of us, does 1-N unidirectional FK relation count as esoteric ? or maybe identifying relationships is esoteric ? or perhaps that is being able to define indexes in the schema ? or maybe this esoteric feature is datastore transactions ? or could it be able to model Collection ? or have a Map with a join table ? or indexed Lists ? or ...

In my opinion, the real annoyance here is that the Java EE spec stack doesn't address how things get into the app-scoped JNDI context. I understand that there are a lot of different possible configurations that different appserver products may need to support, but it seems like there are some pretty common cases (global => app-scoped, for example) that should be included in the Java EE world, just so that the 80% case can be covered in a standard manner.

We did define a standard way of putting something on the app classpath, but standardizing app-scoped names just never made it. It would definitely boost portability, though, and I think most vendors would support it.

So, Patrick, since we're in agreement on this can we focus on defining this for EE 6 instead of you blowing a lot of hot air over some esoteric JDO feature you want to add to JPA? ;-)

One of the great things about the size of the Java EE spec umbrella is that there's plenty of room for all sorts of hot air.
Those of us out here in SF won't be able to blow as much humid air as you guys in New England, though.
-Patrick
--
Patrick Linskey
http://bea.com

However, one of the things EJB3 offers is "configurationless EJB" -- where annotations are used to replace the entries in ejb-jar.xml.

-> To my understanding annotations are an addition. The deployment descripter will override the settings declared with annotations.
Furthermore, you could consider the persistence unit as the resource. The PU will be mapped in JNDI. With a deployment descriptor or annotation you can create the logical and the physical resource reference.

JPA entities are not Java EE "components" so they don't have their own local name environments. They just inherit the environment of the deployed component (they have to be deployed with some component), so it is like asking how to look up something in JNDI from a helper class. You can't declare a resource reference from a persistence unit because there is no Java EE context associated with it. Where would it go, in shared global JNDI?

Therefore, if you want your persistence unit to use a localized datasource name, like java:comp/env/jdbc/myDS, your options are rather limited: you can offer a mapping in an annotation (which is not a very good idea), or you can define your beans in ejb-jar.xml.

Actually, the data source JNDI name in persistence.xml can be mapped in the components that actually deploy/make use of the persistence unit. BTW, it isn't a bad idea to map the resource to a global JNDI name in an annotation. The annotation just shows that the resource is being injected and can specify a default name, and the name can be overridden in an XML resource ref by the deployer if necessary.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.