Okay, there are three sections across two files that deal with
resources. Here are the settings I have, and the confusing results:
ejb-jar.xml
<resource-ref>
<description>Database</description>
<res-ref-name>TestDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
jboss.xml
<resource-managers>
<resource-manager res-class="org.jboss.ejb.deployment.JDBCResource">
<res-name>TestResource</res-name>
<res-jndi-name>xa.TestPool</res-jndi-name>
</resource-manager>
</resource-managers>
jboss.xml - session bean section
<resource-ref>
<res-ref-name>TestDB</res-ref-name>
<resource-name>TestResource</resource-name>
</resource-ref>
The confusing part is that the res-ref-name in the jboss.xml
session bean section and the section in ejb-jar.xml both refer to TestDB,
but nothing is ever bound to that. The JNDI reference is bound to
TestResource. However, both parts are necessary: If you remove the
session bean section in jboss.xml, the bean won't deploy, and if you
remove the chunk from ejb-jar.xml, the resource doesn't get mapped to the
bean's JNDI namespace.
So it seems like every piece has a function, but I question
whether the resource really should have been bound to TestDB or
TestResource. After all, the bean author specified a resource called
TestDB, and it looks like the deployer created a session bean reference to
TestDB (which would refer in turn to the internal TestResource).
Further, I wonder whether it's really appropriate to have the
resource managers section in a jar-specific file. If the resource manager
name has to match the ejb-jar name, then sure. But if we use the
resource-ref in jboss.xml to link the resource manager and the ejb-jar
resource-ref, then the resource manager could be defined at the top level
with the pool itself, and then it could be shared across all beans,
regardless of JARs.
I guess I'm imagining a situation where you have a fair number of
beans (say, 20+) and you choose to package them independently rather than
all in one JAR so you could redeploy individual beans instead of having to
redeploy all at once. But you may want them all to use the same database
pool, and it seems to make sense to have one resource manager rather than
20+ which all have the same name and configuration but are visible to
different beans.
It would be pretty straightforward to include a resource manager
name as a parameter in the pool MBean, and then the pools could each
instantiate the resource manager as they were loaded. Then I guess
(pardon my loose terminology) the bean writer would specify the bean's
resource name, the system admin would specify the resource configuration
and manager, and the deployer would provide the link between the two.
Aaron
