Qs after reviewing Java dynamic metadata resolvers

[Cantor, Scott]

I've filed a couple of bugs after reviewing the code, just had a couple of questions for Brent.

I'm guessing maybe this is already known, but it seems like this design doesn't accomodate artifact resolution if the transformation of the URI is configured into the resolver "once" at wiring time, and then only works against an EntityIDCriterion.

There are a number of ways it could be enhanced I suppose, but I also found it a little strange that the Function interface it's using is String->String vs. CriteriaSet->String. The latter would accomodate an ArtifactSourceIDCriterion for example, and then a Function chain could be used to look for supported Criterion and handle the different cases. As it is, I'm not sure how it would work.

Mostly I'm reviewing the code to see where the best place to add file-backed support would be, because we need to get that into 3.3.

Does the HttpClient support file URIs by any random chance? Probably not I'm guessing.

I guess there are a few ways to do this:

- extend AbstractDynamic[HTTP]MetadataResolver to support failing into backup files
- create a new resolver that's strictly file-based (largely duplicating some of the existing class hierarchy underneath AbstractDynamicHTTPMetadataResolver) and force the deployer to chain to that as a backup
- pull the transport aspect of this out of the class hierarchy and deprecate what's there now

I favor the latter. Basically, I think instead of baking HTTP-awareness into a metadata resolver, we should plug in a new interface that handles metadata acquisition, and that interface can take over the HTTP client case, the existing or extended entityID -> URL transformation job, and include additional support for backing up to files, and simply reading from files.

I guess the biggest downside is more Spring parsing code to build...

-- Scott