My apologies on the link. Not sure how the paste went bad. Here it is:
The exception is that when a Driver class is loaded and registered by an ear-specific class loader, the DriverManager will not return it when DriverManager.getDriver(myURL) is called.
So, am I to assume the following:
You deploy your datasource scoped within an isolated EAR and you want to use this datasource across other deployments in your server?
No - I just want it within the ear. The issue is that the LocalManagedConnectionFactory class is loaded with the primary UnifiedClassLoader3, not by my ear's HeirarchicalLoaderRepository3. While the LocalManagedConnectionFactory.getDriver() method properly uses the current thread's class loader to locate the driver class, the DriverManager does not (as Adrian noted in the Jira issue).
I am just suggesting that the LocalManagedConnectionFactory be modified to use the driver it gets (as it does now after the initial exception) even though the DriverManager isn't smart enough to recognize it.
Taking a hint from Adrian's comments in that Jira issue, I extracted a copy of jboss-local-jdbc.jar from jboss-local-jdbc.rar and put it in my ear (actually, I put it in a .deployer in my ear that contains all my other jars). This solves the issue. To answer the question that Adrian posed in his comments - reloading the ear appears to work fine.
An interesting note - even if the suggestion I made for changing LocalManagedConnectionFactory is adopted, driver loading is not fully isolated unless you have the local copy of the jboss-local-jdbc.jar. If another version of a driver is placed in the central lib directory (e.g. server/default/lib) or in another, not isolated sar or ear, you will get that version of the driver, not the one in your ear. Having your own copy of jboss-local-jdbc.jar appears to be the only full way to isolate drivers from outside interference.
Can you tell my app is deployed in environments where I have to be very careful of what other apps are doing? ;-)