That is a classic problem in a multi classloader environment (like JBoss). Even if the exact same class is loaded by two different classloaders they are NOT the same class in Java.
I would suggest that you remove the JDBC driver (I guess that it is what we are talking about here) from your EAR and keep the one in deployed in JBoss.
Thank you for confirming that this was indeed the problem.
It did felt like it could indeed make the difference between the two classes but I had never (nor my colleagues) heard of that...
My main problem was making sure it would work once deployed and in in our IDE which is why I had bundle the jar file in the EAR.
What I did to fix this was refer to the jar in the Oracle client the developers have locally for the build and remove the one I had put in the EAR. The developers will have to define a classpath variable that point to their Oracle client for their workspace once and I now no longer have to provide the Oracle jar in the EAR.
For some weird reason we didn't have that problem with WebSphere but nothing surprises me anymore, that (externally developed and now maintained in-house) application had quite a few things that relied on WebSphere's quirks (and even after modifying it to make it works on JBoss it still works on WebSphere..)...
Thank you and have a nice day!
Great that the problem is solved.
That it worked on WebSphere may not be weird at all. It all depends on how the application server uses classloaders. Even in older version of JBoss (that using the "Unified Classloader") you "faulty" setup may work in some cases.