oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Kale <davek...@cs.stanford.edu>
Subject Re: Possible problem with "grid" module
Date Fri, 15 Oct 2010 20:44:00 GMT
Paul,

Thanks for the response.  I have a standard Tomcat 5.5.28 set up on my
10.6-running Mac Pro (though I get the same issue on an Ubuntu system that
CMAT set up).  I'm using the Tomcat Manager page to deploy the grid war file
(both the old and the new), and I copy over a backed-up war file after
deployment (but before opening the grid Configure page), so it gets loaded
up when I visit the grid Configure page.

Anyway, I am strongly inclined against the idea that I've somehow messed up
some configuration here or there.  I am following exactly the same procedure
for deploying the old grid module and the new grid module, with the
aforementioned divergent results.  I think there may be something in grid
itself.

I would also add that if you do jar tf on each of the grid war files (old
and new), you see pretty different contents, including some oodt modules
(such as grid-profile/grid-product) that are in the old one but not the new
one (and which, it would seem from looking at them, do some stuff with the
DB props file).  Perhaps the new grid is missing some functionality from
there?

Dave



On Fri, Oct 15, 2010 at 1:26 PM, Ramirez, Paul M (388J) <
paul.m.ramirez@jpl.nasa.gov> wrote:

> Hey Dave,
>
> Where are you putting the config file? Have you tried shutting down Tomcat
> and removing the work directory? This directory is simply a cache Tomcat
> creates and will be recreated when restarted. If you provide a few more
> details on how you are deploying the app and possibly the config file and
> server.xml file for Tomcat I might be able to help out. I haven't deployed
> grid module before but the output below seems like a configuration issue.
>
> Thanks,
> Paul
>
> On Oct 15, 2010, at 1:07 PM, David Kale wrote:
>
> > Hey fellow OODT developers,
> >
> > At CHLA we're trying to deploy the grid module (in conjunction with
> XMLPS)
> > to serve data from a SQL Server.  We had it working with the "old" grid
> > module (from the jpl.eda namespace), but once we substituted the new grid
> > module, we started getting the following:
> >
> > java.sql.SQLException: No suitable driver found for
> > jdbc:sqlserver://[REMOVED]
> >
> > To head off the inevitable questions:
> >
> >   - The jar file with the driver is in the right place, and the config
> >   points to it.
> >   - The config file is, in fact, virtually identical to the config I used
> >   for the "old" grid (only difference is a different query handler, which
> >   isn't relevant)
> >   - Yes, I am using JDK 1.6 (not 1.5), but JDK 1.6 works fine for old
> grid,
> >   so I can't imagine why that would be the issue here
> >
> > It seems inexplicable, but something about substituting the new grid
> module
> > for the old one is messing up whether the jdbc driver gets loaded...?
> >
> > Chris has some ideas about what might be going on, and I'm going to keep
> > debugging, but we wanted to put the conversation out in the public,
> rather
> > than in a Skype window.
> >
> > gratefully,
> > Dave
> >
> > If you want the full stack trace (from catalina.out), here it is:
> >
> > java.sql.SQLException: No suitable driver found for
> > jdbc:sqlserver://[REMOVED]
> >    at java.sql.DriverManager.getConnection(DriverManager.java:602)
> >    at java.sql.DriverManager.getConnection(DriverManager.java:185)
> >    at
> >
> org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
> >    at
> >
> org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
> >    at
> >
> org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
> >    at
> >
> org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
> >    at
> >
> org.apache.oodt.xmlps.product.DBMSExecutor.executeLocalQuery(DBMSExecutor.java:73)
> >    at
> >
> org.apache.oodt.xmlps.product.XMLPSProductHandler.queryAndPackageResults(XMLPSProductHandler.java:234)
> >    at
> >
> org.apache.oodt.xmlps.product.XMLPSProductHandler.query(XMLPSProductHandler.java:131)
> >    at
> >
> edu.usc.chla.vpicu.bigdata.extraction.handlers.PICUDBQueryHandler.query(PICUDBQueryHandler.java:32)
> >    at
> >
> org.apache.oodt.grid.ProductQueryServlet.handleQuery(ProductQueryServlet.java:59)
> >    at org.apache.oodt.grid.QueryServlet.doPost(QueryServlet.java:100)
> >    at org.apache.oodt.grid.QueryServlet.doGet(QueryServlet.java:75)
> >    at javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
> >    at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> >    at
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
> >    at
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
> >    at
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> >    at
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
> >    at
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> >    at
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
> >    at
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
> >    at
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
> >    at
> >
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:873)
> >    at
> >
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
> >    at
> >
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
> >    at
> >
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
> >    at
> >
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
> >    at java.lang.Thread.run(Thread.java:637)
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message