Skip to content
This repository has been archived by the owner on Sep 1, 2022. It is now read-only.

Dap4 requests returns 404 on default catalog (v5.0.0) #1020

Closed
lesserwhirls opened this issue Feb 1, 2018 · 2 comments
Closed

Dap4 requests returns 404 on default catalog (v5.0.0) #1020

lesserwhirls opened this issue Feb 1, 2018 · 2 comments
Assignees

Comments

@lesserwhirls
Copy link
Collaborator

When making a request for DAP4 using the default catalogs that come with TDS 5, I am getting 404's. For example:

http:https://localhost:8080/thredds/dap4/test/testData.nc.dmr.xml

returns:

HTTP Status 404 – Not Found
Type Status Report

Message <Error httpcode="404"> <Message>dap4.core.util.DapException: Not found:
test/testData.nc at thredds.server.dap4.Dap4Controller.getResourcePath(Dap4Controller.java:158) 
at dap4.servlet.DapController.doDMR(DapController.java:305) 
at dap4.servlet.DapController.handleRequest(DapController.java:230) 
at thredds.server.dap4.Dap4Controller.handleRequest(Dap4Controller.java:73) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
<snip>
java.lang.Thread.run(Thread.java:748) </Message> <Context>http:https://localhost:8080/thredds/dap4/test/testData.nc.dmr.xml</Context>

Description The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

The issue is that the getResourcePath(DapRequest drq, String location) method in thredds.server.dap4.Dap4Controller is finds that

String prefix = drq.getResourceRoot()

is not null, and the path is determined using realpath = DapUtil.canonjoin(prefix, location). The value of realpath gets set to

/Users/sarms/dev/unidata/repos/thredds/50/tds/build/libs/exploded/tds-5.0.0-SNAPSHOT.war/WEB-INF/test/testData.nc

which isn't correct. The actual location is properly obtained using realpath = TdsRequestedDataset.getLocationFromRequestPath(location), which sets realpath as:

/Users/sarms/dev/unidata/content/5.0/thredds/public/testdata/testData.nc

TdsRequestedDataset.getLocationFromRequestPath(location) is used in the current code if prefix is null, but in this case, prefix isn't null so the wrong value for realpath is set.

@lesserwhirls lesserwhirls added this to the TDS v5.0.0 beta milestone Feb 1, 2018
@DennisHeimbigner
Copy link
Contributor

DennisHeimbigner commented Mar 5, 2018

Apparently the reason I was doing this is that when I run TestServlet,
which uses mocking, under Intellij,
TdsRequestedDataset.getLocationFromRequestPath(location)
throws an exception. Looks like I need some kind of better way to tell is I am using Mocking.

@DennisHeimbigner
Copy link
Contributor

Turns out that under mocking, TdsRequestedDataset.datasetManager is null.
I suspect this is a Spring wiring issue.

DennisHeimbigner added a commit that referenced this issue Apr 12, 2018
As noted in that issue, the realpath computed from a url suffix
must be done using TdsRequestedDataset.getLocationFromRequestPath().
However, when mocking, it must come from a different mechanism
(See Dap4Controller.getResourcePath()). This is because
I have not succeeded in geting Spring autowiring to work properly
when using controller mocking. This issue occurs in several DAP4
test programs, including TestServlet.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants