Closed lesserwhirls closed 8 years ago
Could you post a full stack trace? I'm unable to replicate this - IOUtils.toString() is certainly capable of handling NoAutoCloseZipInputStream since that's the normal mechanism for reading styles in ncWMS.
Thanks for taking a look! Here is the full stack trace:
java.lang.NullPointerException
at uk.ac.rdg.resc.edal.graphics.style.util.SldTemplateStyleCatalogue.<init>(SldTemplateStyleCatalogue.java:188)
at uk.ac.rdg.resc.edal.graphics.style.util.SldTemplateStyleCatalogue.<clinit>(SldTemplateStyleCatalogue.java:96)
at thredds.server.wms.ThreddsWmsCatalogue.<clinit>(ThreddsWmsCatalogue.java:106)
at thredds.server.wms.ThreddsWmsServlet.dispatchWmsRequest(ThreddsWmsServlet.java:99)
at uk.ac.rdg.resc.edal.wms.WmsServlet.doGet(WmsServlet.java:245)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at thredds.servlet.filter.RequestQueryFilter.doFilter(RequestQueryFilter.java:120)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:316)
at thredds.servlet.filter.RequestBracketingLogMessageFilter.doFilter(RequestBracketingLogMessageFilter.java:81)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at thredds.servlet.filter.RequestCORSFilter.doFilterInternal(RequestCORSFilter.java:81)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at thredds.servlet.filter.RequestQueryFilter.doFilter(RequestQueryFilter.java:120)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at thredds.servlet.filter.HttpHeadFilter.doFilter(HttpHeadFilter.java:46)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:213)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:176)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:344)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:261)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:223)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1517)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1474)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Thanks. I can't see anything which is likely to cause this. Is it easy for you to provide me with the code + config you're running in the TDS setup? Hopefully I can then replicate it and fix whatever's causing it.
The code can be found on my personal github thredds fork under the ncwms2 branch here. I just updated my branch to squash all of my temp commits into one to make the changes I've made easier to see.
I first start the tds using the
-Dtds.content.root.path=/some/empty/dir
During startup, the TDS will populate the empty directory will the default configuration files. I made two simple edits to those default config files:
<allow>
attribute is set to true
.<service name="wms" serviceType="WMS" base="/thredds/wms/" />
to the Compound Service element at the top of the catalog. I've created two gists, one of my threddsConfig.xml and one of my enhancedCatalog.xml, if that make things easier.
Once those two edits are done, you should be able to restart the TDS, and (starting from the top level catalog) navigate to:
Test Enhanced Catalog -> ETA Data
Once there, pick any file. When you click the wms access link, there will be a little pause (initialization of the wms service?) before you get the 500 error.
The stacktrace shows up in tomcat's localhost.<date>.log
file.
Also, all of this work is done on a Mac using Oracle Java 1.8.0_60-b27
and Apache Tomcat 8.0.27
.
I've checked out the project, but I can't build it. When I invoke gradle I get the following:
FAILURE: Build failed with an exception.
What went wrong: A problem occurred evaluating root project 'thredds'.
Could not find method jcenter() for arguments [] on repository container.
BUILD FAILED
Total time: 0.61 secs
Any advice? I need to build TDS with gradle before I can import it into Eclipse so that the dependencies are all in one place - otherwise I'd need to manually configure them (Eclipse really doesn't play nicely with gradle webapps).
Hi @guygriffiths - I hear you on the Eclipse pain. About a year ago I tried it for several months in protest of our intellij license price increasing, but alas, I gave up because I just could not get eclipse to work consistently with gradle.
For the THREDDS project, we actually use the gradle wrapper to build - this ensure you have the correct version of gradle, etc. To build with the wrapper, go to the top level of the source tree and execute:
./gradlew clean assemble
The TDS webapp will be located, relative to the top of the git repo, in
tds/build/libs/tds-5.0.0-SNAPSHOT.war
As a side note, many of the other jars that one expects from the THREDDS project (e.g. netcdfAll, toolsUI, tdm) are located in (again, relative to the top level of the git repo):
build/libs/
Please let me know if the gradle wrapper does the trick!
Cheers,
Sean
Thanks - I remember this now from when I build it previously. However, I'm now getting a build error:
/.../thredds/opendap/src/main/java/opendap/dap/ServerVersion.java:45: error: package com.coverity.security does not exist
import com.coverity.security.Escape;
^
/.../thredds/opendap/src/main/java/opendap/dap/ServerVersion.java:274: error: cannot find symbol
String badVersionMsg = "Invalid XDODS-Server header: " + Escape.html(ver) +
^
symbol: variable Escape
location: class ServerVersion
Hmmm. @JohnLCaron @dopplershift @cwardgar - any ideas? The coverity security lib is included in the opendap modules build.gradle file.
is he compiling with gradle? somehow that dependency isnt there
Yes, he is using our gradle wrapper.
On Tuesday, October 13, 2015, John Caron notifications@github.com wrote:
is he compiling with gradle? somehow that dependency isnt there
— Reply to this email directly or view it on GitHub https://github.com/Reading-eScience-Centre/edal-java/issues/30#issuecomment-147789155 .
I tried to reproduce this but couldn't. First, I deleted all dependencies that Gradle had cached:
rm -rf $HOME/.gradle/caches/
Then:
./gradlew --info clean assemble 1>out.txt 2>&1
and got:
....
Download https://repo1.maven.org/maven2/com/coverity/security/coverity-escapers/1.1.1/coverity-escapers-1.1.1.jar
....
BUILD SUCCESSFUL
So I dunno what the deal is. Gradle builds, when using the wrapper, are supposed to be reproducible everywhere.
Sorry, my own stupidity was at play here - I was not on the correct branch. I'll build it now and try and debug this issue.
So, although it's not coming out nicely in the stack trace, the problem you're seeing is due to the implementation of XPath which you're using. The issue is summarised here: http://stackoverflow.com/questions/798333/classpath-issue-using-xpathfactory and I think you can get around it by using a newer version of Saxon-HE.
I'll look at making this error a bit more explicit.
Hi @guygriffiths - I just wanted to appologize that I never responded to this issue. The fix worked as expected. Thank you!
Greetings @guygriffiths!
I'm working to integrate wms into the TDS again (TDS 5.0, edal-java modules v1.0.2), and I think I have everything hooked up properly. However, when making my first request to the wms server (a basic GetCapabilities request), I get a NPE from the following method when trying to parse the arrow style xml doc:
uk.ac.rdg.resc.edal.graphics.style.sld.StyleSLDParser.parseSLD(Document xmlDocument)
The reason is xml file is not being converted to a string properly by IOUtils in the instantiation of the SldTemplateStyleCatalogue object
uk.ac.rdg.resc.edal.graphics.style.util.SldTemplateStyleCatalogue
(IOUtils.toString() returns an empty string).
Maybe the apache-commons IOUtils.toString() does not know how to handle the NoAutoCloseZipInputStream class defined in SldTemplateStyleCatalogue?