On May 22, 2009, at 11:13 AM, Luis Fernando Planella Gonzalez wrote:
* Several instances of the same application may be deployed in the
same server. So, even that the user could create a data source in
tomcat/conf/openejb.xml, he would have to change each application
instance's META-INF/persistence.xml, which is packed inside a jar,
inside another war. So, this is the showstopper. If weren't for
this, it wouldn't be that bad to make the user set the data source
in the tomcat file.
Still reading the email, but just wanted to post some initial thoughts
on this point. We already don't require you to explicitly set the
data source names in the persistence.xml and will fill them in
automatically in some situations. Our current "guessing" algorithm
wouldn't help you, but we might be able to beef it up to allow for
more kinds of matching. Recently Karsten had a very similar
situation involving multiple persistence units and datasources to
match each:
http://www.nabble.com/Using-Multiple-PersistenceUnits-tp23520311p23534955.html
I suggest there that we might be able to improve the datasource
matching we do for persistence.xml files to look for data sources that
use the persistence unit name when looking for them by the name listed
fails. That won't work for you as you have the same application
deployed several times and would need different datasources for each.
So as another fallback strategy we could maybe match my application
name.
The algorithm for resolving the datasources for a persistence unit
would then look like this:
Look for a datasource whose name matches:
1. the name set in <jta-data-source> or <non-jta-data-source>
2. the name of the persistence-unit
3. the name of the module name (i.e. war, ejb-jar, etc.)
4. the name of the app name (i.e. ear)
Then you could simply leave the <jta-data-source> <non-jta-data-
source> blank and configure a datasource for each application in your
openejb.xml file.
Would something like that work for you? Seems like it would be a good
first step towards what you ultimately want and also a good solution
for Karsten.
-David
