Let’s look at how the primary servlet, opendap.coreServlet.DispatchServlet, handles an incoming DAP service request:

In the opendap.coreServlet.DispatchServlet.doGet() method the code first handles some bookkeeping (such as producing a request id and starting the access log for the request) before iterating over an internal vector of DispatchHandler objects, asking each in turn if it can service the request. The first DispatchHandler to claim the request is then asked to service it and transmit the response. The order of the DispatchHandler objects in the vector is critical, as there are greedy DispatchHandler implementations (FileDispatchHandler for example) that will claim things that should/would have been claimed by the intended DispatchHandler if asked prior. The order is established in the DispatchServlet.init() method.

If the request is for some type of DAP response then the BesDapDispatcher will claim it.

Inside BesDapDispatcher there is a vector of Dap4Responder objects, each one associated with a particular DAP response type (such as: use DAP2 and return a netcdf-3 encoded response, use DAP4 and return the DMR response, etc.) The BesDapDispatcher iterates over its vector of Dap4Responder objects and hands the response duties to the first one that claims the request.

One might ask: How does all this "claiming" work? Through the magic of regular expressions! Each of the Dap4Responder objects contains a primary regular expression which is used to match a URL path in the request. For example the NormativeDMR responder has something like this ^.*\.dmr$. But it’s more complex because in DAP4 there are several different alternate encodings for the DMR (and the other response types as well) that a client might wish to receive. This is handled by having each normative responder hold a collection of alternative responders, each of which has its own suffix and regex. When NormativeDMR is built, it combines all of its alternative responder regex expression into a single combined regex. When NormativeDMR is asked if a request can be handled it simply evaluates the request URL path to see if it matches the combined regex. When the request is submitted for processing NormativeDMR locates the appropriate responder (using the individual regular expressions) and delegates the request to it.

Finally, the chosen responder will set the HTTP response headers appropriately (media types etc.) and then use the BesApi to build and issue a request to the target BES. This is done using a OPeNDAPClient object. The request is passed with the response output stream, and the OPeNDAPClient handles the transmission of the request and then the reception and retransmission of the BES response back to the client.

The RequestCache is used by every thread servicing a request. It’s an object cache. It allows objects to be passed from on part the execution stack to another with it being carried as a parameter. Each thread that’s servicing a request can safely put things it may need into the RequestCache. When the request/response is completed the RequestCache for the thread is cleared. (You can see this in the opendap.coreServlet.DispatchServlet.doGet() method)

The vast majority of the usages of RequestCache are responders caching a MediaType object as a set-up for request execution. This way if an error occurs the error handling apparatus can make good choices about how to encode the error response for the client.

To improve navigation performance, the olfs uses an in-memory LRU cache called BESNodeCache. This is used by the olfs to cache the BES responses to showNode commands (which is how the BES exposes it’s dynamic navigable catalogs). These entries are held for a configurable period of time before a new request for the cached entry will cause the entry to be refreshed. This is a thread safe cache available to all processing threads.

The BesSiteMap class is used to get and maintain a site map file for use with robots.txt The file is refreshed based on a configurable time period.

Hard to know if this even gets used in the real world, so I’m going to skip longer explanation in favor of: For performance reasons the olfs can cache THREDDS catalogs in memory, and it is complicated when the catalogs need to be updated.

A lot of the HTML produced by the server is built using the transforms found in this directory. At this moment (04/01/25) I know that all the files are hooked up to code in the server, but I suspect some of the things that use the xslt files may not be used themselves.

The olfs/resources/hyrax/ngap directory contains the resources that we use amend/replace things from the regular build to produce our NGAP builds. Things like a custom landing page and the libraries to let us use memcached to manage session state in our multi-host deployments.

When the server starts the code in opendap.coreServlet.DispathServlet.init() utilizes the ServletUtil class methods to locate the configuration. The ServletUtil.getConfigPath() method checks the following locations:

If neither of the first two locations are located then the default configuration bundled in the war file will be used.

If either of the first two locations is found, and if the configuration is not in that location, and the running service has write permission to the identified location, then the service will copy its default configuration to the identified location.This creates a configuration that can be easily modified by the operator and that will persist across updates and/or redeployments of the olfs.

The DispatchServlet.init() method also loads a vector with new instances of its DispatchHandler objects that it will utilize to service requests. More on this below.

This file contains the core configuration for the olfs. It defines a number of service behaviors and also the location of the BES(s) to be used when handling requests.

This file is an authentication and permissions control file that allows the operator to deploy a service that can make use of OAUth2 Single Sign On (SSO) to authenticate users. The file also defines the various operational permissions the authenticated users will have (via groups and roles)

These files provide the logging framework behaviors: Log file names, log file content, and what things will be logged at each logging level.

The top level static THREDDS client catalog for the machine traversable THREDDS service. This file nominally contains a catalog ref to the dynamically generated Hyrax THREDDS catalogs:

It can be expanded to create a much more extensive static catalog by creating a filesystem tree of catalog files linked by the appropriate catalogRef elements.

This provides the configuration for the various Java Web Start applications (IDV Viewer, NetcdfToolsUI, etc.) and WebServiceHandlers (NcWMS, Godiva)

I think that this can be retired, but that assertion needs to be tested.

Responders that handle all the DAP2 things. All are children of Dap4Responder. Yeah. I know. Go figure.

Responders that handle all the DAP4 things.

You must first build an authentication/authorization enabled the web archive file, and then you will need to configure the deployment.

Authentication is the operation wherein a users software client establishes that it is working on behalf of a particular user. Use the abstract class IdProvider to capture the common API for an identity provider and provide two implementations, UrsIdP and TomcatRealmIdP. In theory the TomcatRealmIdP should work the Tomcat Memory Authentication Realm, but this has not been verified in years. The UrsIdP knows how to authenticate user with NASA’s Earth Data Login (EDL) service. In NASA speak, UrsIdP is an EDL client. The IdFilter provides the core of the authentication functionality and handles saving request information (Like target URL and query string) in a user session so that it can be used to redirect the client to their original request target when the client returns from a Single Sign On authentication journey.

In this software we define users, groups, and roles in order to create role based access policies. In user-access.xml configuration file we define a group based on one or more "user" definitions:

A role is defined as one more groups and each policy can be applied to one or more roles.

Here’s a policy that allows anyone to access the image and navigable catalog files in Hyrax.

This allows non-authenticated users to look around , and when something bad happens they get a web page rendered with css and images, which they wouldn’t if this rule is not included.

There are problems with the way the form builds dap4 constraint expressions.