[THREDDS #WOQ-367016]: Unexpected Behavior and Questions About the (beta) TDS 5.0
- Subject: [THREDDS #WOQ-367016]: Unexpected Behavior and Questions About the (beta) TDS 5.0
- Date: Mon, 12 Sep 2016 15:27:28 -0600
I'll answer in-line below:
> Good Afternoon Unidata Folks,
> As I'm sure you know we have been doing a bit of testing with the beta
> version of the TDS 5.
> In particular we have been testing the new <catalogScan> directive that can
> be found/used in the catalog.xml file.
> There are two things that we noticed, that were a bit unexpected.
> Sub-directories that have a one character name do not work like directories
> that have more than one character in the name.
> For example a sub-directory named 1/ will behave differently than 10/.
That definitely sounds like a bug. I'll try to reproduce this and debug from
In the meantime, would you mind opening an issue on our github repo?
> To see any example of what is occurring please follow these directions. I
> can provide more detailed examples if needed, and for this process to work
> properly you must be inside the UCAR/NCAR firewall.
We recently moved our machines behind the firewall. I've been working from
home quite a bit due to doctors appointments concerning yet another surgery
(the 30th), and I currently cannot access my machine. I also don't have a VPN
account, although that would probably do the trick. Many things have been
disrupted due to the move behind the firewall, but I hope we can get this worked
> To see this behavior please go to this url:
> Then click on the "NCAR Earth System Scan Directory" link and then click on
> the 1/ directory to get to this url:
> Then click on the 1/ directory again and then a file not found error will
> be shown for this url:
> "FileNotFound: Requested catalog does not exist
> Another hiccup that we've run into that is quite important to us is that
> thredds xml files that are updated in a <catalogScan> directory are not
> reread by the TDS.
> Meaning if this file (for example) is updated with more or fewer or
> different files, the changes do not seem to be automatically picked up and
> displayed by the tds:
Ok, that again sounds like a bug - let me try to reproduce it as well. Does this
seem to apply to certain types of catalog elements (i.e. datasetScans,
featureCollection, Dataset), or is this true across the board? Also, if you
are ok opening a bug on our issue tracker, would you mind opening one for
this as well. Our support mail has been through the roof, so I don't want
this to get lost in the chaos.
> Finally, we have noticed that the url paths have changed slightly between
> the 4.x and 5.x versions of the TDS.
> There is a new /catalog/ section in the url. Is there a configuration
> setting for this in the 5.x TDS or is this just new/expected behavior?
Yes, this is new and expected. Basically, catalog is now exposed as a
service (i.e. /thredds/<service>, whereas before it would sometimes
show up as a service and sometimes not. The change was made to
make catalog consistent with the other services (spring controllers)
like opendap, nciso, or remoteCatalogService. I do believe this made
the catalog controller a bit less cluttered and fragile in the end. Basically,
anything ending with .xml or .html related to catalogs will need to have
/catalog/ in the url now (does not count for the OGC services that return
xml - just thredds catalog xml or the rendered html).
Sorry if that ends up causing a ton of heart ache.
> To see the different behavior between 4.x and 5.x please follow these two
> Which redirects to:
> Which redirects to:
> Which isn't the end of the world, but we will have to update several data
> sources and tools due that change and our preference (if possible) is to
> not do that work. Of course right? :)
> Please let us know if you have any questions or concerns about anything
> written above and please let us know if there is any way that we could
> possible help.
> Thank you for your time, I know your team is quite busy.
Ticket ID: WOQ-367016
Department: Support THREDDS
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.