Reading-eScience-Centre / edal-java

Environmental Data Abstraction Layer libraries
Other
39 stars 30 forks source link

Error parsing style on first wms request #30

Closed lesserwhirls closed 8 years ago

lesserwhirls commented 9 years ago

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?

guygriffiths commented 9 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.

lesserwhirls commented 9 years ago

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)
guygriffiths commented 9 years ago

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.

lesserwhirls commented 9 years ago

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:

  1. Edit threddsConfig.xml and uncomment the elements, making sure that the <allow> attribute is set to true.
  2. Edit enhancedCatalog.xml to add
<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.

guygriffiths commented 9 years ago

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.

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).

lesserwhirls commented 9 years ago

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

guygriffiths commented 9 years ago

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
lesserwhirls commented 9 years ago

Hmmm. @JohnLCaron @dopplershift @cwardgar - any ideas? The coverity security lib is included in the opendap modules build.gradle file.

JohnLCaron commented 9 years ago

is he compiling with gradle? somehow that dependency isnt there

lesserwhirls commented 9 years ago

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 .

cwardgar commented 9 years ago

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.

guygriffiths commented 9 years ago

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.

guygriffiths commented 9 years ago

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.

lesserwhirls commented 8 years ago

Hi @guygriffiths - I just wanted to appologize that I never responded to this issue. The fix worked as expected. Thank you!