1 Reply Latest reply on Dec 18, 2010 3:48 AM by Willem Jiang

    CXF and ClassNotFound, is my theory right?

    Jon Calvert Newbie

      Up front detail: Using Fuse 4.3.0


      So I ended up on a bit of a goosechase last night, and in trying to figure out why, I'd love to get some feedback on my theory to see if it is sound.


      Deployed an application to a new environment and ultimately we discovered there was a Postgres user configuration error; basically user A can't login to the DB from IP B, but they can from C.


      The application uses CXF to expose some services via JAX-WS. The goosechase that I went on though was that service calls that didn't require database connectivity were working beautifully. But ones that did were throwing an exception. Thus, I tailed the log file and saw a root java.lang.ClassNotFoundException: org.postgresql.Driver


      I was totally confused since the PG driver bundle was deployed and I'd used the same features file to deploy to other machines. Later, I noticed that above that exception was

      Caused by: java.lang.ClassNotFoundException: org.postgresql.Driver not found from bundle


      I thought: "Whoa! Why is the CXF bundle needing to see the driver?". Given the timing, I did something I knew is a no-no and enabled dynamic imports on CXF. I did that and then the credentials issue started coming through. Once the credentials issue was fixed, I disabled dynamic imports and everything was working dandy.


      So my theory anyway relies on the fact that the not found from bundle exception has a

      "at org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1135)" in it.


      Bundle gets deployed, Spring sees the DataSource bean, tries to create it. Fails because of bad credentials. Dao objects use Hibernate, so then at runtime tries to reinitialize the bean. This happens in the context of CXF, since it is handling the incoming SOAP call, and since CXF does not import the Driver, that's why I was getting the exception. Does this sound about right? What could I have done differently to have gotten the underlying cause faster? Obviously if I had paid closer attention to the logging right at bundle startup, I would have seen it, but this application had already been running for a while, and I would liked to have diagnosed the issue without restarting. Is it to fail fast? But I also want the application to be robust enough to recover from connection hiccups without human intervention.


      Any input is greatly appreciated!




        • 1. Re: CXF and ClassNotFound, is my theory right?
          Willem Jiang Master

          It's really dependents on how you create the application context which expose the services from CXF. CXF will try to load the application context with the CXF bundle class loader as fallback of loading the application context with thread context class loader.


          I don't understand your statements of "so then at runtime tries to reinitialize the bean."


          Can you tell me in what kind of satiation that you get the exception? Did you restart your application bundle?