[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: understanding the jar files in thredds.war

Hi Tennessee:

Sorry I havent had a chance to respond until now.

We decided to start using the dods-1.1.4.jar release instead of recompiling it from source. We needed to replace DConnect (and DODServlet?) for some reason (ill have to check why). The easiest way is to just include it in the classpath before the dods.jar file. Are you seeing some evidence that somehow that is screwing up? Try putting -verbose on the JVM, you should be able to tell unambiguously where things get loaded from.

I really apologize for not having a real source release that you can track all this down with. We will make a new release in the next month or two, using netcdf-java-2.2, and it will build from source.

Tennessee Leeuwenburg wrote:

Hi all,

I've found some more strange things going on with thredds in my effort to trace the exception I'm seeing when trying to access the files served up by my servlet (it serves up netCDF files from a custom database based on url parameters). (errors cause caused by a NullPointerException thredds - I believe the result of DConnect passing a null string to ServerVersion after trying to get a non-existent HTTP header, trace below)

The class dods.servlet.DODSServlet is being resourced from WEB-INF/lib/dods-1.1.4.jar, and not from WEB-INF/classes/dods/servlet/DODSServlet.jar.

I found what seemed to be inconsistency with a similar issue accessing DConnect.class, which is similarly available from two places - it seems like it might be sometimes loaded from one place and sometimes from another, as the debugging output I put in there isn't showing up for all URLs. (i.e. the debugging output shows up for data from my servlet, but not from apache, despite being well above where the problems are occurring when trying to load my data).

Obviously it's possible that there's something I'm missing in terms of program logic, but having two different .class files "just isn't right" in my book, it adds confusion about which resource is to be used.

I will try to go through the process of trimming out the un-neccesary .class files and come back to the list with a tidied report of what's used, but it would be good to get some feedback as to whether this is a useful thing to do, whether there is a rule of thumb about which class is "supposed" to be used etc.

So far I've been debugging through a mixture of looking at source code from the ftp server (for the .jars) and diffing the .class files to confirm whether classes are varying.


DODServlet ERROR (anyExceptionHandler): java.lang.NullPointerException requestState: dataset: 'foo.nc' suffix: 'dds' CE: '' compressOK: false InitParameters: maxAggDatasetsCached: '20' maxNetcdfFilesCached: '100' maxDODSDatasetsCached: '100' displayName: 'THREDDS/DODS Aggregation/NetCDF/Catalog Server'

at dods.dap.ServerVersion.<init>(ServerVersion.java:45)
at dods.dap.DConnect.openConnection(DConnect.java:207)
at dods.dap.DConnect.getDDS(DConnect.java:278)
at ucar.nc2.dods.DODSNetcdfFile.<init>(DODSNetcdfFile.java:150)
at ucar.nc2.dods.DODSNetcdfFile.<init>(DODSNetcdfFile.java:106)
at ucar.nc2.dataset.NetcdfDataset.tryDODS(NetcdfDataset.java:107)
at ucar.nc2.dataset.NetcdfDataset.factory(NetcdfDataset.java:85)
at dods.servers.netcdf.NcDataset.<init>(NcDataset.java:137)
at dods.servers.netcdf.NcDataset.<init>(NcDataset.java:38)
at dods.servers.netcdf.NcDataset$NetcdfFactory.factory(NcDataset.java:69)
at dods.servers.agg.CacheDataset.acquire(CacheDataset.java:142)
at dods.servers.netcdf.NcDataset.acquire(NcDataset.java:88)
at dods.servers.agg.CatalogServlet.getDataset(CatalogServlet.java:657)
at dods.servlet.DODSServlet.doGetDDS(DODSServlet.java:569)
at dods.servlet.DODSServlet.doGet(DODSServlet.java:1548)
at dods.servers.agg.CatalogServlet.doGet(CatalogServlet.java:527)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.