Hi!
Aaron Mulder wrote:
>
> 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).
It's a bug. You are quite correct. I have fixed it now and will include
it in the next CVS commit. Thanks for catching this.
> 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.
Note that the resource manager does not implement any functionality but
rather simply binds a java: name to a global JNDI-name, so what you're
referring to will indeed happen: several beans/applications can share
the same pools.
> 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.
Well, if we really want to shortcut this then the deployer could put the
JNDI-name as the resource name in jboss.xml (and entirely skip resource
managers). However, this will not work well on a large scale, and
especially when resources that are not datasources and which are not
global are used, such as URL's or mail sessions. I'm thinking about this
from an "apphotel" point of view, where loads of apps will play
together. Having them share a database in the backend is one thing, but
creating global mail sessions is another and would not work well.
Nevertheless, the bug you found above was important, and has been fixed
(not in CVS yet though). Great!!
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
