First invocation on newly started server always throws exception

[jamoore]

Due to driver issues, the first DB access in Omero will always throw the
following exception:

Caused by: org.jboss.resource.JBossResourceException: Apparently wrong driver
class specified for URL: class: org.postgresql.Driver, url:
jdbc:postgresql://localhost/ome-meta?protocolVersion=2
 at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.getDriver(LocalManagedConnectionFactory.java:274)
 at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:168)
  ... 38 more

Simply re-running the call will fix the problem. Cause is currently unknown.

Originally : ​http://bugs.openmicroscopy.org.uk/show_bug.cgi?id=649

Note: The comment in bug 649 about driver versions is most likely incorrect. Various combinations (also with newer servers) have been tried. It is rather probably a classloader issue. See ​this forum archive

(Copied here since it doesn't seem to be a reliable URL):

Adrian@Jboss.Org 12 March 2005 01:32:02

It means the driver-class/url are incompatible.
I've also seen this problem when there is an internal problem within the driver,
e.g. classes missing or other bizarre internal error.

Chirayath 27 January 2006 13:29:11

Hi,
Put the proper driver jar file in server/default/lib folder of JBoss installation folder.

Regards,
Joby

[jmoore]

Have found a workaround which forces the exception during startup using a JMX @Service (JBoss-specific). Will need to review it later however.

[jmoore]

r1108 works around this in our own way. Rather than trying to make jboss/postgres behave, we just force the exception during startup.

[jmoore]

​http://www.jroller.com/page/agileanswers?entry=preventing_java_s_java_lang#comments also suggests putting the postgres jar under server/lib and not in the EAR.

[jmoore]

Just tried out putting the postgres driver under JBOSS_HOME/server/default/deploy/lib . It works! Do we document this as a standard practice or just keep the workaround?

[jmoore]

It'd still be good to get an opinion on documenting the lib/ solution, but closing, since our workaround definitely prevents the client from seeing this issue.