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

[THREDDS #JRP-282661]: Fwd: WMS in THREDDS 5



Greetings Alan,

So the main reason the WMS service isn't working in ESGF is because
the web xml is missing all of the necessary information to map the
wms  request urls to the wms code:

<!-- edal-wms servlet -->

  <servlet>
    <servlet-name>wms</servlet-name>
    <servlet-class>thredds.server.wms.ThreddsWmsServlet</servlet-class>
    <load-on-startup>2</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>wms</servlet-name>
    <url-pattern>/wms/*</url-pattern>
  </servlet-mapping>

  <filter>
    <filter-name>RequestQueryFilter</filter-name>
    <filter-class>thredds.servlet.filter.RequestQueryFilter</filter-class>
  </filter>

  <filter-mapping>
    <filter-name>RequestQueryFilter</filter-name>
    <servlet-name>wms</servlet-name>
  </filter-mapping>

  <!-- end edal-wms servlet -->

You can try adding the xml snippet above to the web.xml file shipped
with the ESGF release, but it may take more work than that. I'd 
highly recommend contacting them to see why they removed it and
to see what it would take to add it back (there are likely security
issues related to this).

As for the 404, this one is a bit more tricky. Is it possible that the ESGF
TDS has special credentials to access the data off of disk? One way to test
would be to take three or so files from the directory:

/neodc/esacci/cloud/data/phase-2/L3C/AVHRR-PM/v2.0

and put them in a temporary directory in the tomcat users home directory.
Then, update catalog.xml and use the new path in the location attribute of the
scan element in the ncml aggregation. Be sure to use the vanilla TDS.

If that does not work, is there a way I could get three or so of the 
AVHRR-PM/v2.0
files you are using so that I can debug locally?

Cheers,

Sean

> Sean,
> 
> Okay, I decided to look at the AggTest now.  I am getting a 404 with
> the opendap.  The WMS gives a java.io.FileNotFoundException.  But the
> scan location does exist (and I can access it okay when I "su" to the
> tomcat user).  What should I try now please?
> 
> Thanks,
> Alan
> 
> On 13 October 2017 at 18:31, Alan Iwi (STFC) <address@hidden> wrote:
> > Sean,
> >
> > Here's the web.xml to quickly answer your point 2.  I'll look at your
> > point 1 also, but it might be next week.
> >
> > Regards,
> > Alan
> >
> > On 13 October 2017 at 18:12, Unidata THREDDS Support
> > <address@hidden> wrote:
> >> Oops...here is the attachment.
> >>
> >> Sean
> >>
> >>> Greetings Alan,
> >>>
> >>> The reason I had you try with the vanilla TDS war and and simple example
> >>> was to see if we could even access WMS on your server, or if there was
> >>> a potential issue outside of the TDS (maybe Tomcat, Apache, etc). Given
> >>> that the simple test works, it looks like the issue is related to a 
> >>> difference
> >>> in the esgf bundled TDS.
> >>>
> >>> There are two things I'd like to try now.
> >>>
> >>> 1) Try the aggregation with the vanilla TDS by adding the following
> >>> to the main catalog.xml (the one with the simple datasetScan that works):
> >>>
> >>> <dataset ID="Aggtest"
> >>> name="AggTest"
> >>> urlPath="AggTest">
> >>>
> >>> <metadata>
> >>> <dataType>GRID</dataType>
> >>> </metadata>
> >>>
> >>> <netcdf xmlns="http://www.unidata.ucar.edu/namespaces/netcdf/ncml-2.2";>
> >>> <aggregation dimName="time" type="joinExisting">
> >>> <variableAgg name="cee"/>
> >>> <variableAgg name="cee_corr_unc"/>
> >>> <scan location="/neodc/esacci/cloud/data/phase-2/L3C/AVHRR-PM/v2.0" 
> >>> suffix=".nc"/>
> >>> </aggregation>
> >>> </netcdf>
> >>> </dataset>
> >>>
> >>> between the </datasetScan> and </catalog> entries at the end of the 
> >>> catalog.xml file.
> >>> Note I've attached an updated copy of catalog.xml with the changes in 
> >>> case the xml
> >>> snippets above do not show up in this message. Check to see if things 
> >>> still work in the first
> >>> dataset, and then see if they work with your aggregation. Try hitting the 
> >>> opendap link
> >>> of your aggregation dataset first to make sure it does not return a 404 
> >>> or 500.
> >>>
> >>> 2) Can you send me the thredds/WEB-INF/web.xml file from the webapps 
> >>> directory
> >>> included with the ESGF distribution?
> >>>
> >>> Thanks!
> >>>
> >>> Sean
> >>>
> >>> > Changing the address to the support address as Sean requested.]
> >>> >
> >>> > I have tried with the a top-level catalogue containing both the "test
> >>> > all files in a directory" <datasetScan> element and also the "Earth
> >>> > System Root" <catalogRef> element containing files published by the
> >>> > ESGF publisher.  I have tried this with both the vanilla thredds.war
> >>> > file you supplied and also with the thredds directory from ESGF.
> >>> >
> >>> > The situation now seems to be:
> >>> >
> >>> > 1) if I try with the vanilla thredds.war file you supplied, then the
> >>> > "test all files in a directory" link in your test top-level catalogue
> >>> > seem to work, including the WMS links, but I have two problems:
> >>> >
> >>> > (a) it is a very different example from the one which I was trying to
> >>> > get working, and I do not know how to adapt it -- namely, it has a
> >>> > <datasetScan> which finds a bunch of datasets consisting of one file
> >>> > each, whereas I want to serve a single dataset but that dataset is to
> >>> > consist of an aggregation of netCDF files
> >>> >
> >>> > (b) with the vanilla thredds.war file, I do not have the changes made
> >>> > by ESGF, and if I try to use a catalogue produced by the ESGF
> >>> > publisher then it does not work, for example with the HTTPServer links
> >>> > it redirects to /thredds/restrictedAccess/esg-user and then Chrome
> >>> > reports "ERR_INVALID_HTTP_RESPONSE", and if I insert WMS links then I
> >>> > get a NullPointerException.
> >>> >
> >>> > 2) If I reinstate the thredds/ directory supplied by ESGF (removing
> >>> > the vanilla thredds directory and thredds.war), then we are back where
> >>> > we were before, namely that the datasets published by the ESGF
> >>> > publisher work as regards access methods other than wms (e.g.
> >>> > HTTPServer), but /thredds/wms and any URLs below it get a 404 error.
> >>> >
> >>> > 3) I also tried to merge the two (use the later versions of the .jar
> >>> > files but import the ESGF xml changes), but this did not work (I think
> >>> > 500 errors), and to be honest, I don't really know which differences
> >>> > to import.
> >>> >
> >>> > I forgot to attach to my last email the diffs between the two
> >>> > directories.  They are now reattached.
> >>> >
> >>> > Any help appreciated.
> >>> >
> >>> > Thanks,
> >>> > Alan
> >>> >
> >>> > On 12 October 2017 at 16:35, Sean Arms <address@hidden> wrote:
> >>> > > Greetings Alan,
> >>> > >
> >>> > > The ESGF group makes some changes to WEB-INF/web.xml for security 
> >>> > > related
> >>> > > things (authentication / authorization, I believe), and so they ship 
> >>> > > the
> >>> > > "exploded war file", which is just the directory. If Tomcat 
> >>> > > determines the
> >>> > > actual war file in the webapps directory is newer than what is in the
> >>> > > exploded directory, it will overwrite it and all the custom security 
> >>> > > stuff
> >>> > > will be removed. So, the ESGF group simply ships the directory rather 
> >>> > > than
> >>> > > the war so that they can assure the changes they make will stay in 
> >>> > > place
> >>> > > when tomcat is restarted.
> >>> > >
> >>> > > The files under altContent are the default TDS config files. If the
> >>> > > directory that is specified using the tds.content.root.path variable 
> >>> > > in
> >>> > > setenv.sh is empty or does not exist, the TDS will create it and 
> >>> > > populate it
> >>> > > with these files. As you have found, they are never actually read 
> >>> > > directly.
> >>> > > Everything you need to edit is going to be in the 
> >>> > > tds.content.root.path
> >>> > > directory.
> >>> > >
> >>> > > The diff of the two thredds webapps directory didn't make it though - 
> >>> > > would
> >>> > > you mind sending it again? Given that you were able to get wms to 
> >>> > > respond
> >>> > > with the vanilla TDS, I'm thinking ESGF has tweaked something, 
> >>> > > probably in
> >>> > > WEB-INF/, that is preventing the ESGF distribution from being able to 
> >>> > > "see"
> >>> > > the WMS server properly.
> >>> > >
> >>> > > We'll get this figured out - it just might take a little more time :-)
> >>> > >
> >>> > > Cheers,
> >>> > >
> >>> > > Sean
> >>> > >
> >>> > >
> >>> > >
> >>> > > On Wed, Oct 11, 2017 at 7:54 PM, Alan Iwi (STFC) <address@hidden>
> >>> > > wrote:
> >>> > >>
> >>> > >> Sean,
> >>> > >>
> >>> > >> I also attach a recursive diff between the original thredds webapp
> >>> > >> directory (renamed webapps.tmp/thredds) and the new one as
> >>> > >> automatically extracted by tomcat from your new thredds.war file.
> >>> > >>
> >>> > >> By the way, I think the lines I put into
> >>> > >> webapps/thredds/WEB-INF/altContent/startup/threddsConfig.xml are not
> >>> > >> significant.  I subsequently discovered (with strace) that it is not
> >>> > >> reading that file, and that the active threddsConfig.xml lives in the
> >>> > >> directory with the catalog.xml (outside the webapps directory).  The
> >>> > >> active one is the threddsConfig.xml that I already attached to an
> >>> > >> earlier email, and I never bothered to edit back the one under
> >>> > >> altContent.
> >>> > >>
> >>> > >> Thanks,
> >>> > >> Alan
> >>> > >>
> >>> > >> On 12 October 2017 at 02:46, Alan Iwi (STFC) <address@hidden> wrote:
> >>> > >> > Sean,
> >>> > >> >
> >>> > >> > Okay well, it's the middle of the night for me and maybe you've
> >>> > >> > finished now anyway, but I thought I'd try to turn this around 
> >>> > >> > quickly
> >>> > >> > just in case...
> >>> > >> >
> >>> > >> > I tried with your vanilla .war file and it seemed to work.
> >>> > >> >
> >>> > >> > Specifically, the webapps directory previously contained an 
> >>> > >> > extracted
> >>> > >> > thredds directory (and no .war file).  I moved this subdirectory 
> >>> > >> > out
> >>> > >> > of the way (out of the webapps directory), and in its place I put 
> >>> > >> > the
> >>> > >> > new thredds.war without extracting it.  I then started the server
> >>> > >> > using the usual top-level script provided by ESGF, and did not 
> >>> > >> > modify
> >>> > >> > the JAVA_OPTS to point to the config dir because it's already in
> >>> > >> > principle set up.  For now, I am still using your root catalogue .
> >>> > >> >
> >>> > >> > Now when I click on the WMS link, I get the XML file which I have
> >>> > >> > attached (the attachment filename was my choice rather than 
> >>> > >> > anything
> >>> > >> > provided by the server).  It seems that tomcat has extracted the 
> >>> > >> > .war
> >>> > >> > file automatically so there is now both thredds/ and thredds.war .
> >>> > >> >
> >>> > >> > Tomorrow I can try investigating further -- in particular, trying 
> >>> > >> > it
> >>> > >> > with the catalogues that I was trying to use originally.
> >>> > >> >
> >>> > >> > Regards,
> >>> > >> > Alan
> >>> > >> >
> >>> > >> >
> >>> > >> > On 12 October 2017 at 02:22, Alan Iwi (STFC) <address@hidden>
> >>> > >> > wrote:
> >>> > >> >> Sean,
> >>> > >> >>
> >>> > >> >> Thanks very much.  I'll have a look tomorrow.
> >>> > >> >>
> >>> > >> >> In case I get stuck further, what time tomorrow will you have 
> >>> > >> >> time to
> >>> > >> >> look at it?  I'm just wondering whether it is worth me planning 
> >>> > >> >> to try
> >>> > >> >> to overlap with you again if it's not too late.
> >>> > >> >>
> >>> > >> >> Many thanks,
> >>> > >> >> Alan
> >>> > >> >>
> >>> > >> >>
> >>> > >> >> On 11 October 2017 at 23:26, Sean Arms <address@hidden> wrote:
> >>> > >> >>> Oops, you also likely need to add the following after the 
> >>> > >> >>> JAVA_OPTS
> >>> > >> >>> line in
> >>> > >> >>> setenv.sh:
> >>> > >> >>>
> >>> > >> >>> export JAVA_OPTS
> >>> > >> >>>
> >>> > >> >>> Also, if your tomcat users shell isn't bash, you'll need to add 
> >>> > >> >>> the
> >>> > >> >>> following to the top of setenv.sh:
> >>> > >> >>>
> >>> > >> >>> #!/bin/sh
> >>> > >> >>>
> >>> > >> >>> Sorry if you already know these things - just covering the bases 
> >>> > >> >>> :-)
> >>> > >> >>>
> >>> > >> >>> Cheers,
> >>> > >> >>>
> >>> > >> >>> Sean
> >>> > >> >>>
> >>> > >> >>>
> >>> > >> >>> On Wed, Oct 11, 2017 at 4:23 PM, Sean Arms <address@hidden> 
> >>> > >> >>> wrote:
> >>> > >> >>>>
> >>> > >> >>>> This is very interesting. DAP4 isn't working yet, so that's 
> >>> > >> >>>> expected,
> >>> > >> >>>> but
> >>> > >> >>>> it is not expected for WMS. I'm wondering if something gets 
> >>> > >> >>>> changed
> >>> > >> >>>> during
> >>> > >> >>>> the process in which the ESGF group bundles in the TDS into 
> >>> > >> >>>> their
> >>> > >> >>>> installation process. Would it be possible for you to test with 
> >>> > >> >>>> a
> >>> > >> >>>> vanilla
> >>> > >> >>>> TDS install? You can grab the war file here:
> >>> > >> >>>>
> >>> > >> >>>>
> >>> > >> >>>>
> >>> > >> >>>> https://artifacts.unidata.ucar.edu/content/repositories/unidata-releases/edu/ucar/tds/ESGF-5.0.1/tds-ESGF-5.0.1.war
> >>> > >> >>>>
> >>> > >> >>>> You'll need to rename the war file to thredds.war, or
> >>> > >> >>>> thredds##esgf-5.0.1.war before putting it in the tomcat webapps
> >>> > >> >>>> directory.
> >>> > >> >>>> You'll also need to edit the tomcat bin/setenv.sh to add the
> >>> > >> >>>> following:
> >>> > >> >>>>
> >>> > >> >>>> JAVA_OPTS=-Dtds.content.root.path=</some/path/for/tds/configs>
> >>> > >> >>>>
> >>> > >> >>>> Sorry for the craziness - I don't see anything funky in the 
> >>> > >> >>>> config
> >>> > >> >>>> files
> >>> > >> >>>> you sent, so I am wondering if we can even get a plain TDS 
> >>> > >> >>>> install
> >>> > >> >>>> working.
> >>> > >> >>>>
> >>> > >> >>>> Cheers,
> >>> > >> >>>>
> >>> > >> >>>> Sean
> >>> > >> >>>>
> >>> > >> >>>>
> >>> > >> >>>> On Wed, Oct 11, 2017 at 1:35 PM, Alan Iwi (STFC)
> >>> > >> >>>> <address@hidden>
> >>> > >> >>>> wrote:
> >>> > >> >>>>>
> >>> > >> >>>>> Sean,
> >>> > >> >>>>>
> >>> > >> >>>>> I also attach here the threddsConfig.xml file in case it helps.
> >>> > >> >>>>>
> >>> > >> >>>>> Thanks,
> >>> > >> >>>>> Alan
> >>> > >> >>>>>
> >>> > >> >>>>> On 11 October 2017 at 20:31, Alan Iwi (STFC) <address@hidden>
> >>> > >> >>>>> wrote:
> >>> > >> >>>>> > Sean,
> >>> > >> >>>>> >
> >>> > >> >>>>> > Thanks for your help.  I installed your top-level catalogue, 
> >>> > >> >>>>> > and
> >>> > >> >>>>> > if I
> >>> > >> >>>>> > click on one of the test files I get a bunch of links.
> >>> > >> >>>>> >
> >>> > >> >>>>> > OPENDAP: /thredds/dodsC/testAll/2004050400_eta_211.nc.html
> >>> > >> >>>>> > CdmRemote: /thredds/cdmremote/testAll/2004050400_eta_211.nc
> >>> > >> >>>>> > CdmrFeature:
> >>> > >> >>>>> > /thredds/cdmrfeature/grid/testAll/2004050400_eta_211.nc
> >>> > >> >>>>> > DAP4: /thredds/dap4/testAll/2004050400_eta_211.nc.dmr.xml
> >>> > >> >>>>> > HTTPServer: /thredds/fileServer/testAll/2004050400_eta_211.nc
> >>> > >> >>>>> > NetcdfSubset:
> >>> > >> >>>>> > /thredds/ncss/grid/testAll/2004050400_eta_211.nc/dataset.html
> >>> > >> >>>>> > WMS: /thredds/wms/testAll/2004050400_eta_211.nc
> >>> > >> >>>>> > WCS: /thredds/wcs/testAll/2004050400_eta_211.nc
> >>> > >> >>>>> > ISO: /thredds/iso/testAll/2004050400_eta_211.nc
> >>> > >> >>>>> > NCML: /thredds/ncml/testAll/2004050400_eta_211.nc
> >>> > >> >>>>> > UDDC: /thredds/uddc/testAll/2004050400_eta_211.nc
> >>> > >> >>>>> >
> >>> > >> >>>>> > Of these, all the following links all do something:
> >>> > >> >>>>> >
> >>> > >> >>>>> > OPENDAP
> >>> > >> >>>>> > CdmRemote
> >>> > >> >>>>> > CdmrFeature
> >>> > >> >>>>> > HTTPServer
> >>> > >> >>>>> > NetcdfSubset
> >>> > >> >>>>> > WCS
> >>> > >> >>>>> > ISO
> >>> > >> >>>>> > NCML
> >>> > >> >>>>> > UDDC
> >>> > >> >>>>> >
> >>> > >> >>>>> > and just the following two links give 404s:
> >>> > >> >>>>> >
> >>> > >> >>>>> > DAP4
> >>> > >> >>>>> > WMS
> >>> > >> >>>>> >
> >>> > >> >>>>> > I attach the catalogInit.log obtained after installing your
> >>> > >> >>>>> > catalog.xml.
> >>> > >> >>>>> >
> >>> > >> >>>>> > Thanks,
> >>> > >> >>>>> > Alan
> >>> > >> >>>>> >
> >>> > >> >>>>> >
> >>> > >> >>>>> >
> >>> > >> >>>>> > On 11 October 2017 at 20:19, Sean Arms <address@hidden> 
> >>> > >> >>>>> > wrote:
> >>> > >> >>>>> >> Greetings Alan,
> >>> > >> >>>>> >>
> >>> > >> >>>>> >> Can you give this root catalog a try? Make sure to keep 
> >>> > >> >>>>> >> it's name
> >>> > >> >>>>> >> as
> >>> > >> >>>>> >> catalog.xml and put it in the top level content directory 
> >>> > >> >>>>> >> of the
> >>> > >> >>>>> >> TDS
> >>> > >> >>>>> >> (<tds.content.root.path>/thredds/). Also, can you send me 
> >>> > >> >>>>> >> the TDS
> >>> > >> >>>>> >> catalogInit.log log file?
> >>> > >> >>>>> >> (<tds.content.root.path>/thredds/logs/catalogInit.log?)
> >>> > >> >>>>> >>
> >>> > >> >>>>> >> Cheers,
> >>> > >> >>>>> >>
> >>> > >> >>>>> >> Sean
> >>> > >> >>>>> >>
> >>> > >> >>>>> >>
> >>> > >> >>>>> >>
> >>> > >> >>>>> >> On Wed, Oct 11, 2017 at 1:05 PM, Alan Iwi (STFC)
> >>> > >> >>>>> >> <address@hidden>
> >>> > >> >>>>> >> wrote:
> >>> > >> >>>>> >>>
> >>> > >> >>>>> >>> Sean,
> >>> > >> >>>>> >>>
> >>> > >> >>>>> >>> I tried your revised client catalogue, and I am still 
> >>> > >> >>>>> >>> getting a
> >>> > >> >>>>> >>> 404.
> >>> > >> >>>>> >>> And my test with the plain /thredds/wms/ URL (where I get 
> >>> > >> >>>>> >>> a 404
> >>> > >> >>>>> >>> instead of the ServiceExceptionReport document) rather 
> >>> > >> >>>>> >>> suggests
> >>> > >> >>>>> >>> to me
> >>> > >> >>>>> >>> that I have a configuration problem which is going to mean 
> >>> > >> >>>>> >>> that
> >>> > >> >>>>> >>> I
> >>> > >> >>>>> >>> continue to get these 404 errors *regardless* of the 
> >>> > >> >>>>> >>> contents of
> >>> > >> >>>>> >>> the
> >>> > >> >>>>> >>> client catalogue.  It seems to me that - at a high level
> >>> > >> >>>>> >>> independent
> >>> > >> >>>>> >>> of any particular dataset - THREDDS does not know what to 
> >>> > >> >>>>> >>> do
> >>> > >> >>>>> >>> with
> >>> > >> >>>>> >>> these wms URLs.  How can I debug this please?
> >>> > >> >>>>> >>>
> >>> > >> >>>>> >>> (I have also looked at your configuration catalogue, but I 
> >>> > >> >>>>> >>> am
> >>> > >> >>>>> >>> struggling to see what it corresponds to on my system.)
> >>> > >> >>>>> >>>
> >>> > >> >>>>> >>> Thanks,
> >>> > >> >>>>> >>> Alan
> >>> > >> >>>>> >>>
> >>> > >> >>>>> >>>
> >>> > >> >>>>> >>> On 11 October 2017 at 19:54, Alan Iwi (STFC)
> >>> > >> >>>>> >>> <address@hidden>
> >>> > >> >>>>> >>> wrote:
> >>> > >> >>>>> >>> > Sean,
> >>> > >> >>>>> >>> >
> >>> > >> >>>>> >>> > Thanks.  I'll give it a go...
> >>> > >> >>>>> >>> >
> >>> > >> >>>>> >>> > Regards,
> >>> > >> >>>>> >>> > Alan
> >>> > >> >>>>> >>> >
> >>> > >> >>>>> >>> > On 11 October 2017 at 19:32, Sean Arms <address@hidden> 
> >>> > >> >>>>> >>> > wrote:
> >>> > >> >>>>> >>> >> Greetings Alan,
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >> You won't be able to use the xml from our server 
> >>> > >> >>>>> >>> >> directly, as
> >>> > >> >>>>> >>> >> that
> >>> > >> >>>>> >>> >> is a
> >>> > >> >>>>> >>> >> client catalog and not a configuration catalog. The
> >>> > >> >>>>> >>> >> configuration
> >>> > >> >>>>> >>> >> catalog
> >>> > >> >>>>> >>> >> looks like this:
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >> https://github.com/Unidata/TdsConfig/blob/master/threddsDev/idd/forecastModels.xml
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >> Now, of course, this catalog has many GRIB 
> >>> > >> >>>>> >>> >> featureCollection
> >>> > >> >>>>> >>> >> elements,
> >>> > >> >>>>> >>> >> which
> >>> > >> >>>>> >>> >> are not helpful in your case. But, notice how there 
> >>> > >> >>>>> >>> >> isn't any
> >>> > >> >>>>> >>> >> <service>
> >>> > >> >>>>> >>> >> or
> >>> > >> >>>>> >>> >> <serviceName> elements anywhere in the catalog.
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >> For your example catalog, mytest.xml, I've updated a few
> >>> > >> >>>>> >>> >> things
> >>> > >> >>>>> >>> >> (see
> >>> > >> >>>>> >>> >> attached). Give this catalog a try and see how it does.
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >> Thanks!
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >> Sean
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >> On Wed, Oct 11, 2017 at 11:50 AM, Alan Iwi (STFC)
> >>> > >> >>>>> >>> >> <address@hidden>
> >>> > >> >>>>> >>> >> wrote:
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> Sean,
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> I've now done the following tests, which convince me 
> >>> > >> >>>>> >>> >>> that
> >>> > >> >>>>> >>> >>> the
> >>> > >> >>>>> >>> >>> problem
> >>> > >> >>>>> >>> >>> is somehow with our server setup rather than with the
> >>> > >> >>>>> >>> >>> dataset
> >>> > >> >>>>> >>> >>> catalogue.
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> One is a very simple one, that if I just go to:
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> https://esgf-test-install.ceda.ac.uk/thredds/wms/
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> then I get a 404, whereas if I go to:
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> http://thredds-dev.unidata.ucar.edu/thredds/wms/
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> then I get an XML file with a ServiceExceptionReport .
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> (NB, you won't see our test server as it is firewalled 
> >>> > >> >>>>> >>> >>> off.)
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> The other test involves fetching one of your 
> >>> > >> >>>>> >>> >>> catalogues and
> >>> > >> >>>>> >>> >>> trying to
> >>> > >> >>>>> >>> >>> serve it from our server -- described in more detail 
> >>> > >> >>>>> >>> >>> below,
> >>> > >> >>>>> >>> >>> but
> >>> > >> >>>>> >>> >>> the
> >>> > >> >>>>> >>> >>> summary is that the HTTPServer works and the WMS 
> >>> > >> >>>>> >>> >>> doesn't.
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> Where would I go from here to work out why the server 
> >>> > >> >>>>> >>> >>> does
> >>> > >> >>>>> >>> >>> not
> >>> > >> >>>>> >>> >>> know
> >>> > >> >>>>> >>> >>> what to do with /thredds/wms URLs?
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> Thanks,
> >>> > >> >>>>> >>> >>> Alan
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> [details of second test follow]
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> ==================================================================
> >>> > >> >>>>> >>> >>> * wget the following XML from your server to mine, 
> >>> > >> >>>>> >>> >>> saving as
> >>> > >> >>>>> >>> >>> a
> >>> > >> >>>>> >>> >>> local
> >>> > >> >>>>> >>> >>> file in the thredds directory
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> http://thredds-dev.unidata.ucar.edu/thredds/catalog/grib/NCEP/NBM/Alaska/National_Blend_Alaska_20170911_0000.grib2/catalog.xml
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> * edit it, making the following changes (only):
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>>  - in VirtualServices, comment out all except wms
> >>> > >> >>>>> >>> >>>  - in fullServices, comment out all except HTTPServer 
> >>> > >> >>>>> >>> >>> and
> >>> > >> >>>>> >>> >>> wms
> >>> > >> >>>>> >>> >>>  - search and replace the relative path of the data 
> >>> > >> >>>>> >>> >>> file to
> >>> > >> >>>>> >>> >>> point
> >>> > >> >>>>> >>> >>> to
> >>> > >> >>>>> >>> >>> esg_dataroot/National_Blend_Alaska_20170911_0000.grib2
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>>    where esg_dataroot is one of the data roots set up, 
> >>> > >> >>>>> >>> >>> and I
> >>> > >> >>>>> >>> >>> drop
> >>> > >> >>>>> >>> >>> into
> >>> > >> >>>>> >>> >>> there a world-readable copy of the data file which I
> >>> > >> >>>>> >>> >>> downloaded
> >>> > >> >>>>> >>> >>> from
> >>> > >> >>>>> >>> >>> your server using the HTTPServer URL
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> * set a global allow policy in the esg-orp security 
> >>> > >> >>>>> >>> >>> layer
> >>> > >> >>>>> >>> >>> for any
> >>> > >> >>>>> >>> >>> URL
> >>> > >> >>>>> >>> >>> matching .*Alaska.*
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> * link this XML file from top level catalog and do a 
> >>> > >> >>>>> >>> >>> reinit
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> * try accessing over http
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> The result is a catalogue that has a working 
> >>> > >> >>>>> >>> >>> HTTPServer link
> >>> > >> >>>>> >>> >>> and
> >>> > >> >>>>> >>> >>> a
> >>> > >> >>>>> >>> >>> broken WMS link.  See attached:
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> 1) the XML file from the filesystem  (the XML as 
> >>> > >> >>>>> >>> >>> served by
> >>> > >> >>>>> >>> >>> THREDDS is
> >>> > >> >>>>> >>> >>> the same as this except for the omission of the 
> >>> > >> >>>>> >>> >>> comments and
> >>> > >> >>>>> >>> >>> adding
> >>> > >> >>>>> >>> >>> 'zpositive="up"' in the geospatialCoverage element).
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> 2) HTML as served by THREDDS
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> 3) for convenience, screenshot of the HTML in my 
> >>> > >> >>>>> >>> >>> browser
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> The HTTPServer link works (file is downloaded), and 
> >>> > >> >>>>> >>> >>> the WMS
> >>> > >> >>>>> >>> >>> link
> >>> > >> >>>>> >>> >>> gives
> >>> > >> >>>>> >>> >>> a
> >>> > >> >>>>> >>> >>> 404.
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> ==================================================================
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>>
> >>> > >> >>>>> >>> >>> On 11 October 2017 at 17:11, Alan Iwi (STFC)
> >>> > >> >>>>> >>> >>> <address@hidden>
> >>> > >> >>>>> >>> >>> wrote:
> >>> > >> >>>>> >>> >>> > Sean,
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > In case any use, I am sending here what I am getting 
> >>> > >> >>>>> >>> >>> > in a
> >>> > >> >>>>> >>> >>> > simplified
> >>> > >> >>>>> >>> >>> > example.
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > Attached is the dataset catalogue, and also 
> >>> > >> >>>>> >>> >>> > screenshots as
> >>> > >> >>>>> >>> >>> > follows
> >>> > >> >>>>> >>> >>> > (clicking through from the top-level catalogue):
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > 1.png
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > https://esgf-test-install.ceda.ac.uk/thredds/catalog/catalog.html
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > 2.png
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > https://esgf-test-install.ceda.ac.uk/thredds/catalog/mytest.html
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > 3.png
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > https://esgf-test-install.ceda.ac.uk/thredds/catalog/mytest.html?dataset=mytest
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > 4.png
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > https://esgf-test-install.ceda.ac.uk/thredds/wms/mytest?service=WMS&version=1.3.0&request=GetCapabilities
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > The top-level XML file has:
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> >   <WMS>
> >>> > >> >>>>> >>> >>> >     <allow>true</allow>
> >>> > >> >>>>> >>> >>> >     <allowRemote>false</allowRemote>
> >>> > >> >>>>> >>> >>> >     <maxImageWidth>2048</maxImageWidth>
> >>> > >> >>>>> >>> >>> >     <maxImageHeight>2048</maxImageHeight>
> >>> > >> >>>>> >>> >>> >   </WMS>
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > directly inside the <threddsConfig> element.
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > Please say if I should send anything from the log 
> >>> > >> >>>>> >>> >>> > file to
> >>> > >> >>>>> >>> >>> > accompany
> >>> > >> >>>>> >>> >>> > it.
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > But also, maybe if I see the XML code and any config 
> >>> > >> >>>>> >>> >>> > file
> >>> > >> >>>>> >>> >>> > stuff
> >>> > >> >>>>> >>> >>> > behind
> >>> > >> >>>>> >>> >>> > your working example, I could try to work forward 
> >>> > >> >>>>> >>> >>> > from
> >>> > >> >>>>> >>> >>> > there?
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > Thanks again,
> >>> > >> >>>>> >>> >>> > Alan
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> >
> >>> > >> >>>>> >>> >>> > On 11 October 2017 at 14:55, Alan Iwi (STFC)
> >>> > >> >>>>> >>> >>> > <address@hidden>
> >>> > >> >>>>> >>> >>> > wrote:
> >>> > >> >>>>> >>> >>> >> Sean,
> >>> > >> >>>>> >>> >>> >>
> >>> > >> >>>>> >>> >>> >> Thanks very much.  I think there is something I'm 
> >>> > >> >>>>> >>> >>> >> not
> >>> > >> >>>>> >>> >>> >> understanding,
> >>> > >> >>>>> >>> >>> >> though.  If I have the <service name=...> and
> >>> > >> >>>>> >>> >>> >> <serviceName>
> >>> > >> >>>>> >>> >>> >> elements
> >>> > >> >>>>> >>> >>> >> both included, then I get a WMS link but it gives a 
> >>> > >> >>>>> >>> >>> >> 404
> >>> > >> >>>>> >>> >>> >> if I
> >>> > >> >>>>> >>> >>> >> click
> >>> > >> >>>>> >>> >>> >> on
> >>> > >> >>>>> >>> >>> >> it.  If I comment either of them out, then there is 
> >>> > >> >>>>> >>> >>> >> no
> >>> > >> >>>>> >>> >>> >> link
> >>> > >> >>>>> >>> >>> >> visible
> >>> > >> >>>>> >>> >>> >> at
> >>> > >> >>>>> >>> >>> >> all.
> >>> > >> >>>>> >>> >>> >>
> >>> > >> >>>>> >>> >>> >> Please could I have a look at what the relevant 
> >>> > >> >>>>> >>> >>> >> catalog
> >>> > >> >>>>> >>> >>> >> XML
> >>> > >> >>>>> >>> >>> >> file
> >>> > >> >>>>> >>> >>> >> looks
> >>> > >> >>>>> >>> >>> >> like in your working example?  (Sorry if this is
> >>> > >> >>>>> >>> >>> >> something I
> >>> > >> >>>>> >>> >>> >> can
> >>> > >> >>>>> >>> >>> >> see
> >>> > >> >>>>> >>> >>> >> for myself over http, but I'm not sure what the URL 
> >>> > >> >>>>> >>> >>> >> would
> >>> > >> >>>>> >>> >>> >> be.)
> >>> > >> >>>>> >>> >>> >>
> >>> > >> >>>>> >>> >>> >> Thanks,
> >>> > >> >>>>> >>> >>> >> Alan
> >>> > >> >>>>> >>> >>> >>
> >>> > >> >>>>> >>> >>> >> On 10 October 2017 at 16:02, Sean Arms 
> >>> > >> >>>>> >>> >>> >> <address@hidden>
> >>> > >> >>>>> >>> >>> >> wrote:
> >>> > >> >>>>> >>> >>> >>> Greetings Ag, Alan,
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>> Sorry for the delay - I've been out and am playing 
> >>> > >> >>>>> >>> >>> >>> a bit
> >>> > >> >>>>> >>> >>> >>> of
> >>> > >> >>>>> >>> >>> >>> catch
> >>> > >> >>>>> >>> >>> >>> up
> >>> > >> >>>>> >>> >>> >>> still.
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>> The WMS service should be working in TDS 5 - here 
> >>> > >> >>>>> >>> >>> >>> is an
> >>> > >> >>>>> >>> >>> >>> example on
> >>> > >> >>>>> >>> >>> >>> our
> >>> > >> >>>>> >>> >>> >>> TDS
> >>> > >> >>>>> >>> >>> >>> dev server:
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>> http://thredds-dev.unidata.ucar.edu/thredds/wms/grib/NCEP/GFS/Global_0p25deg/GFS_Global_0p25deg_20171010_0600.grib2?service=WMS&version=1.3.0&request=GetCapabilities
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>> This is running a 5.0 snapshot version from this 
> >>> > >> >>>>> >>> >>> >>> past
> >>> > >> >>>>> >>> >>> >>> March;
> >>> > >> >>>>> >>> >>> >>> I'm
> >>> > >> >>>>> >>> >>> >>> pretty sure
> >>> > >> >>>>> >>> >>> >>> the latest ESGF release is using a more up-to-date
> >>> > >> >>>>> >>> >>> >>> version.
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>> One of the changes made to the TDS in version 5.0 
> >>> > >> >>>>> >>> >>> >>> is the
> >>> > >> >>>>> >>> >>> >>> concept
> >>> > >> >>>>> >>> >>> >>> of
> >>> > >> >>>>> >>> >>> >>> default
> >>> > >> >>>>> >>> >>> >>> services. I've encountered a few places where 
> >>> > >> >>>>> >>> >>> >>> explicitly
> >>> > >> >>>>> >>> >>> >>> defining
> >>> > >> >>>>> >>> >>> >>> a
> >>> > >> >>>>> >>> >>> >>> service
> >>> > >> >>>>> >>> >>> >>> in a catalog causes errors, while not defining any
> >>> > >> >>>>> >>> >>> >>> services
> >>> > >> >>>>> >>> >>> >>> for a
> >>> > >> >>>>> >>> >>> >>> dataset
> >>> > >> >>>>> >>> >>> >>> works (as long as the dataset you are serving 
> >>> > >> >>>>> >>> >>> >>> includes
> >>> > >> >>>>> >>> >>> >>> "<dataType>GRID</dataType>" in the datasets 
> >>> > >> >>>>> >>> >>> >>> metadata. I
> >>> > >> >>>>> >>> >>> >>> am
> >>> > >> >>>>> >>> >>> >>> wondering
> >>> > >> >>>>> >>> >>> >>> if WMS
> >>> > >> >>>>> >>> >>> >>> is one of those services. Could you try removing 
> >>> > >> >>>>> >>> >>> >>> all
> >>> > >> >>>>> >>> >>> >>> "<serviceName>"
> >>> > >> >>>>> >>> >>> >>> and
> >>> > >> >>>>> >>> >>> >>> <service name=...>" elements from the catalog and 
> >>> > >> >>>>> >>> >>> >>> see if
> >>> > >> >>>>> >>> >>> >>> that
> >>> > >> >>>>> >>> >>> >>> works?
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>> If that does not work, would it be possible for me 
> >>> > >> >>>>> >>> >>> >>> to
> >>> > >> >>>>> >>> >>> >>> get a
> >>> > >> >>>>> >>> >>> >>> sample
> >>> > >> >>>>> >>> >>> >>> of
> >>> > >> >>>>> >>> >>> >>> the
> >>> > >> >>>>> >>> >>> >>> dataset you are working with?
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>> Cheers,
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>> Sean
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>> On Tue, Oct 10, 2017 at 6:11 AM,
> >>> > >> >>>>> >>> >>> >>> <address@hidden>
> >>> > >> >>>>> >>> >>> >>> wrote:
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> Hi Sean,
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> We are trying to look into this issue this week. 
> >>> > >> >>>>> >>> >>> >>>> It
> >>> > >> >>>>> >>> >>> >>>> would be
> >>> > >> >>>>> >>> >>> >>>> great if
> >>> > >> >>>>> >>> >>> >>>> you
> >>> > >> >>>>> >>> >>> >>>> could get back to Alan regarding the WMS on TDS5.0
> >>> > >> >>>>> >>> >>> >>>> question.
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> It would save us a heap of time if it is now 
> >>> > >> >>>>> >>> >>> >>>> working in
> >>> > >> >>>>> >>> >>> >>>> TDS5.0.
> >>> > >> >>>>> >>> >>> >>>> :-)
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> Many thanks,
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> Ag
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> -----Original Message-----
> >>> > >> >>>>> >>> >>> >>>> From: address@hidden
> >>> > >> >>>>> >>> >>> >>>> [mailto:address@hidden On
> >>> > >> >>>>> >>> >>> >>>> Behalf
> >>> > >> >>>>> >>> >>> >>>> Of Alan Iwi (STFC)
> >>> > >> >>>>> >>> >>> >>>> Sent: 04 October 2017 10:12
> >>> > >> >>>>> >>> >>> >>>> To: address@hidden
> >>> > >> >>>>> >>> >>> >>>> Cc: Stephens, Ag (STFC,RAL,RALSP); Kershaw, Philip
> >>> > >> >>>>> >>> >>> >>>> (STFC,RAL,RALSP)
> >>> > >> >>>>> >>> >>> >>>> Subject: WMS in THREDDS 5
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> Dear Sean,
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> Ag Stephens gave me your name as the current 
> >>> > >> >>>>> >>> >>> >>>> contact
> >>> > >> >>>>> >>> >>> >>>> for TDS
> >>> > >> >>>>> >>> >>> >>>> development.
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> Please can you tell me whether WMS is believed to 
> >>> > >> >>>>> >>> >>> >>>> be
> >>> > >> >>>>> >>> >>> >>>> working
> >>> > >> >>>>> >>> >>> >>>> in
> >>> > >> >>>>> >>> >>> >>>> TDS
> >>> > >> >>>>> >>> >>> >>>> 5.
> >>> > >> >>>>> >>> >>> >>>> We are already using WMS in TDS 4, but it would be
> >>> > >> >>>>> >>> >>> >>>> convenient if
> >>> > >> >>>>> >>> >>> >>>> it
> >>> > >> >>>>> >>> >>> >>>> is
> >>> > >> >>>>> >>> >>> >>>> also working in 5, because then we could serve it 
> >>> > >> >>>>> >>> >>> >>>> from
> >>> > >> >>>>> >>> >>> >>>> the
> >>> > >> >>>>> >>> >>> >>>> same
> >>> > >> >>>>> >>> >>> >>>> THREDDS
> >>> > >> >>>>> >>> >>> >>>> deployment as we are using for the file download 
> >>> > >> >>>>> >>> >>> >>>> and
> >>> > >> >>>>> >>> >>> >>>> the
> >>> > >> >>>>> >>> >>> >>>> opendap
> >>> > >> >>>>> >>> >>> >>>> service --
> >>> > >> >>>>> >>> >>> >>>> currently we have to manage content on two 
> >>> > >> >>>>> >>> >>> >>>> different
> >>> > >> >>>>> >>> >>> >>>> servers
> >>> > >> >>>>> >>> >>> >>>> in
> >>> > >> >>>>> >>> >>> >>>> order
> >>> > >> >>>>> >>> >>> >>>> to
> >>> > >> >>>>> >>> >>> >>>> serve different access methods for the same 
> >>> > >> >>>>> >>> >>> >>>> datasets.
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> Our TDS 4 deployment is on a standalone Tomcat
> >>> > >> >>>>> >>> >>> >>>> installation
> >>> > >> >>>>> >>> >>> >>>> (installed
> >>> > >> >>>>> >>> >>> >>>> from RPM), but I am now trying to enable WMS in 
> >>> > >> >>>>> >>> >>> >>>> TDS
> >>> > >> >>>>> >>> >>> >>>> 5.0.0
> >>> > >> >>>>> >>> >>> >>>> which
> >>> > >> >>>>> >>> >>> >>>> is
> >>> > >> >>>>> >>> >>> >>>> part of a
> >>> > >> >>>>> >>> >>> >>>> deployment of the latest ESGF software stack on a 
> >>> > >> >>>>> >>> >>> >>>> test
> >>> > >> >>>>> >>> >>> >>>> node.
> >>> > >> >>>>> >>> >>> >>>> When I try it, I get a 404 response for all URLs 
> >>> > >> >>>>> >>> >>> >>>> under
> >>> > >> >>>>> >>> >>> >>>> /thredds/wms/,
> >>> > >> >>>>> >>> >>> >>>> and
> >>> > >> >>>>> >>> >>> >>>> nothing in the catalina.{out,err} files or 
> >>> > >> >>>>> >>> >>> >>>> THREDDS log
> >>> > >> >>>>> >>> >>> >>>> files.
> >>> > >> >>>>> >>> >>> >>>> There is also no mention of wms (or WMS) in the
> >>> > >> >>>>> >>> >>> >>>> serverStartup.log:
> >>> > >> >>>>> >>> >>> >>>> the
> >>> > >> >>>>> >>> >>> >>>> serverStartup log for TDS 4 has messages about
> >>> > >> >>>>> >>> >>> >>>> FrameworkServlet
> >>> > >> >>>>> >>> >>> >>>> initialization for both 'root' and 'wms', whereas 
> >>> > >> >>>>> >>> >>> >>>> the
> >>> > >> >>>>> >>> >>> >>>> serverStartup
> >>> > >> >>>>> >>> >>> >>>> log for
> >>> > >> >>>>> >>> >>> >>>> TDS 5 only has one for 'spring', so it is handling
> >>> > >> >>>>> >>> >>> >>>> things
> >>> > >> >>>>> >>> >>> >>>> differently
> >>> > >> >>>>> >>> >>> >>>> in a
> >>> > >> >>>>> >>> >>> >>>> way I don't know the details of.
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> I am enabling the service everywhere that I am 
> >>> > >> >>>>> >>> >>> >>>> aware
> >>> > >> >>>>> >>> >>> >>>> of.  In
> >>> > >> >>>>> >>> >>> >>>> particular, I
> >>> > >> >>>>> >>> >>> >>>> am putting the relevant <service> elements and
> >>> > >> >>>>> >>> >>> >>>> corresponding
> >>> > >> >>>>> >>> >>> >>>> <access
> >>> > >> >>>>> >>> >>> >>>> serviceName="wms"...> in the dataset catalog.
> >>> > >> >>>>> >>> >>> >>>> Also the threddsConfig.xml for TDS 5 already has 
> >>> > >> >>>>> >>> >>> >>>> WMS
> >>> > >> >>>>> >>> >>> >>>> enabled
> >>> > >> >>>>> >>> >>> >>>> (with an
> >>> > >> >>>>> >>> >>> >>>> "allow" element containing text "true").  I know 
> >>> > >> >>>>> >>> >>> >>>> that
> >>> > >> >>>>> >>> >>> >>>> the
> >>> > >> >>>>> >>> >>> >>>> request
> >>> > >> >>>>> >>> >>> >>>> is
> >>> > >> >>>>> >>> >>> >>>> being
> >>> > >> >>>>> >>> >>> >>>> forwarded through to tomcat, as it appears in the
> >>> > >> >>>>> >>> >>> >>>> Tomcat
> >>> > >> >>>>> >>> >>> >>>> access
> >>> > >> >>>>> >>> >>> >>>> log.
> >>> > >> >>>>> >>> >>> >>>> It
> >>> > >> >>>>> >>> >>> >>>> also seems that the esg-orp is filtering the 
> >>> > >> >>>>> >>> >>> >>>> request
> >>> > >> >>>>> >>> >>> >>>> per
> >>> > >> >>>>> >>> >>> >>>> normal,
> >>> > >> >>>>> >>> >>> >>>> because if
> >>> > >> >>>>> >>> >>> >>>> I change the part of the URL after /thredds/wms 
> >>> > >> >>>>> >>> >>> >>>> so that
> >>> > >> >>>>> >>> >>> >>>> the
> >>> > >> >>>>> >>> >>> >>>> full
> >>> > >> >>>>> >>> >>> >>>> URL
> >>> > >> >>>>> >>> >>> >>>> no
> >>> > >> >>>>> >>> >>> >>>> longer matches the pattern for open access, then 
> >>> > >> >>>>> >>> >>> >>>> this
> >>> > >> >>>>> >>> >>> >>>> changes the
> >>> > >> >>>>> >>> >>> >>>> response.
> >>> > >> >>>>> >>> >>> >>>> (In fact this generates an error, because our 
> >>> > >> >>>>> >>> >>> >>>> current
> >>> > >> >>>>> >>> >>> >>>> esg-orp
> >>> > >> >>>>> >>> >>> >>>> deployment
> >>> > >> >>>>> >>> >>> >>>> seems to have some bug relating to protected 
> >>> > >> >>>>> >>> >>> >>>> resources,
> >>> > >> >>>>> >>> >>> >>>> but
> >>> > >> >>>>> >>> >>> >>>> the
> >>> > >> >>>>> >>> >>> >>>> details are
> >>> > >> >>>>> >>> >>> >>>> probably not important here because is not 
> >>> > >> >>>>> >>> >>> >>>> affecting
> >>> > >> >>>>> >>> >>> >>>> openly
> >>> > >> >>>>> >>> >>> >>>> accessible
> >>> > >> >>>>> >>> >>> >>>> resources.)
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> Is there anything else I need to do to make it 
> >>> > >> >>>>> >>> >>> >>>> work, or
> >>> > >> >>>>> >>> >>> >>>> do I
> >>> > >> >>>>> >>> >>> >>>> just
> >>> > >> >>>>> >>> >>> >>>> have to
> >>> > >> >>>>> >>> >>> >>>> continue to use the THREDDS 4 deployment instead?
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> Any advice appreciated.
> >>> > >> >>>>> >>> >>> >>>>
> >>> > >> >>>>> >>> >>> >>>> Many thanks,
> >>> > >> >>>>> >>> >>> >>>> Alan
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>> >>>
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>> >>
> >>> > >> >>>>> >>
> >>> > >> >>>>> >>
> >>> > >> >>>>
> >>> > >> >>>>
> >>> > >> >>>
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>
> >>
> >> Ticket Details
> >> ===================
> >> Ticket ID: JRP-282661
> >> Department: Support THREDDS
> >> Priority: Normal
> >> Status: Open
> >> ===================
> >> 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.
> 
> 

Ticket Details
===================
Ticket ID: JRP-282661
Department: Support THREDDS
Priority: Normal
Status: Open
===================
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.



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.