Problems creating MySQL Datasource in OC4J

Question

I was recently tasked with creating a MySQL datasource in my development OC4J container (running through Eclipse, but that's irrelevant). I searched for and found this page: http://www.oracle.com/technology/products/jdev/tips/duff/mysql_and_oc4j3.html which tells me how to do this.
I searched for and found the Datasource class jar file: mysql-connector-java-3.0.17-ga-bin.jar, installing it in the ORACLE_HOME/applib directory of my container.
I then fired up the container, and accessed the ascontrol app to add the Datasource (via Administration/JDBC options), and ran into a few problems:
After entering the "Create Datasource" menu, I filled in the appropriate values for the JNDI name, class name of the Datasource, URL of the database, username and password. When I went to test the connection, I received an error that the Datasource class could not be created, yet in the error message it showed me where the Datasource class was (in which jar), so obviously the container knew about the jar.
After much playing around, I determined that the ascontrol app itself was the issue. In the orion-application.xml file for the ascontrol found in ORACLE_HOME/application-deployments/ascontrol, I found the line:
<remove-inherited name="global.libraries"/>
in the <imported-shared-libraries> tag. This essentially means, "ignore everything in the applib directory". It seems, as the instructions in the page above state, you actually have to manually edit the data-sources.xml file in your ORACLE_HOME/config directory in order to add this datasource, as the ascontrol app is unable to do so without loading the library from applib.
Now, I just commented out this line in the ascontrol's xml file temporarily, and was able to use the ascontrol to add the datasource, but this seems wrong. Now, finally, I can ask my questions:
1. Is this really the preferred method for adding a MySQL datasource to an OC4J container?
2. If not, what is?
3. If so, why is the ascontrol crippled in this fashion, and should it be fixed so it isn't anymore?

Answer 1

Tank -- we recently discovered this situation with ASC ourselves. There's some history there in that by importing the global.libraries in the past, there has been problems with some libs that ASC itself needed being overridden -- evidently some common practice with a framework we supply was to use the applib directory in this manner, which caused issues for ASC. So the solution was to remove global.libraries from ASC.
OK so how to solve it, there's a number of options.
1. Remove the remove-inherited libraries tag from the ASC deployment descriptor as you've identified. I actually have the ASC team checking on whether this is something they want to do in a patch release.
2. Put the mysql driver into its own installed shared-library, then import that into each app that needs it. And add it to ASC as an imported-shared-library. That way the same code-source is available in each location. I'd have to say this is probably the preferred option at this point.
3. Put the mysql jar file into both the j2ee/home/applib directory AND the web-inf/lib directory of the so both apps have at it. This introduces an abstract dependency, which may cause issues if you update one but not the other at some future point. But it should work.
cheers
-steve-