Re: understanding the jar files in thredds.war
- To: Tennessee Leeuwenburg <address@hidden>
- Subject: Re: understanding the jar files in thredds.war
- From: John Caron <address@hidden>
- Date: Tue, 21 Dec 2004 18:28:46 -0800
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:
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
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
displayName: 'THREDDS/DODS Aggregation/NetCDF/Catalog Server'
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.