WIP: Way of counting bytes sent through stream to end-user such that it can be recorded in access log

The main issue is that we need to get definitive stats on file
access/download.  Till now there has been a heuristic applied to the
only bit of data we really had which was the duration of download
time.  This, however, didn't give the logging fidelity we needed.

After a bit of digging, the least invasive mechanism was to augment
the AccessLoggingFilter so that it would pass data through a new
output stream.  This output stream would simply count the bits being
posted and, via a callback, send the number of total bytes moved into
the database.

What is missing is determining the bytes in the file in question.  And
also... to test if this thing works!!! :-)  It compiles, which usually
means it is all good (famous last words).
try catching any errors ...
In prep for testing, having debug output in place
got total num bits for a transfer
preparing for making servlet 3.0 calls for data size, and collecting xfer bytes info
postgres scripts to alter access_logging table to include additional fields for content and xfer file sizes
More consistent with var names
Pulling in servlet-ap v3.0.1 to build against - need for getting http headers

This newer version of the servlet api allows the counting filter to
get HTTP headers from the response; namely Content-Length.
Not packaging servlet-api jar with war distribution
WIP - have to resolve requested URL to filesystem file to get size.

Stubbed out the resolving function...
WIP to get mount point resolving
WIP: updated with Log calls and cleaned up stuff...
Stripping the [http://node.name:port/<svc_prefix>]/foo/bar/alpha.nc from encountered urls and sending off to be resolved
WIP - trying to get mount point resolver in play... currently slogging through
sorting issue.
WIP: including imports...
Does god resolution of mount points... but...

In doing some testing it was very strange that an entry was omitted.
I am not sure why...

see...

length of esg_dataroot_aa = 15 ? length of esg_dataroot/1 = 14
length of esg_dataroot_aaa = 16 ? length of esg_dataroot/1 = 14
length of esg_dataroot_aaa = 16 ? length of esg_dataroot_aa = 15
length of esg_dataroot_aaaa = 17 ? length of esg_dataroot_aa = 15
length of esg_dataroot_aaaa = 17 ? length of esg_dataroot_aaa = 16
length of esg_dataroot = 12 ? length of esg_dataroot_aa = 15
length of esg_dataroot = 12 ? length of esg_dataroot/1 = 14
length of esg_dataroot/1/2/3 = 18 ? length of esg_dataroot_aa = 15
length of esg_dataroot/1/2/3 = 18 ? length of esg_dataroot_aaa = 16
length of esg_dataroot/1/2/3 = 18 ? length of esg_dataroot_aaaa = 17
length of esg_dataroot/1/2 = 17 ? length of esg_dataroot_aa = 15
length of esg_dataroot/1/2 = 17 ? length of esg_dataroot_aaaa = 17
Adding mountpoint: esg_dataroot/1/2/3 --> /esg/data/one/two/three
Adding mountpoint: esg_dataroot_aaaa --> /esg/data/a/a/a/a
Adding mountpoint: esg_dataroot_aaa --> /esg/data/a/a/a
Adding mountpoint: esg_dataroot_aa --> /esg/data/a/a
Adding mountpoint: esg_dataroot/1 --> /esg/data/one
Adding mountpoint: esg_dataroot --> /esg/data

Resolving /esg_dataroot/1/2/test/foo.nc
Resolved to local path: [/esg/data/one/2/test/foo.nc]

What I entered as the mount map is:
        Map<String,String> m = new java.util.HashMap<String,String>();
        m.put("esg_dataroot/1/2","/esg/data/one/two");
        m.put("esg_dataroot/1/2/3","/esg/data/one/two/three");
        m.put("esg_dataroot","/esg/data");
        m.put("esg_dataroot/1","/esg/data/one");
        m.put("esg_dataroot_aa","/esg/data/a/a");
        m.put("esg_dataroot_aaaa","/esg/data/a/a/a/a");
        m.put("esg_dataroot_aaa","/esg/data/a/a/a");

NOTICE

        m.put("esg_dataroot/1/2","/esg/data/one/two");

is missing from the mount point inventory!
I can reproduce this with other strings! Hmm.....

does "/2" mean something to the comparator?
Code for reading, loading and resolving "mounted" urls -to-> local filesystem files
a bit of clean up and defensive coding...
Plan A in play!