We have a few mule projects which have started using the Microsoft jdbc 4.0 driver (namely, sqljdbc_auth.dll and the sqljdbc4-4.0.jar). One thing we ran into when we attempted to install multiple mule apps that used the driver into the same mule app server is that we’d get an error message that the dll was already loaded … and of course, at the point, an exception would be thrown and the app was essentially, uselessly, dead.
The solution is actually pretty straight-forward. You first want to specify the dependency on the driver as being a “provided” scope dependency within maven. Something like this works just fine:
This way, when you build the deployment zip file for your app, the sqljdbc4-4.0.jar is not included.
Next, make sure your mule app server has the sqljdbc_auth.dll in the $MULE_HOME/lib/native directory, and the sqljdbc4-4.0.jar in the $MULE_HOME/lib/user directory.
Finally, modify the mule wrapper.conf file to include the setting of the java library path so that provided dlls are picked up when the mule app container is started. We used
(where, of course, replace C:\esb\mule\mymuleserver with the path to your own server, $MULE_HOME).
Now, make sure no other apps in that particular mule app server references the provided dependency (in our case, the Microsoft jdbc driver). If it does … you’ll have to modify that projects dependency as described above.
If you’re clean … restart the mule server. The sqljdbc_auth.dll will now be loaded in the context of the mule server and not individual apps, and you won’t have collisions with multiple apps trying to load the dll.
This is applicable, of course, to any dependency on a jar and/or dll which may cause collisions when loaded/used by more than one app in a single mule container. The names may change, but the story is the same …