HTTPResource and multiple Metadata Provider files

[Cantor, Scott]

> The use case is that we want a centrally managed file of UC-specific
> "approved" entity attributes that each campus will apply to the InCommon
> aggregate locally.
> 
> We also figure that campuses will need a facility to “override” our centrally
> managed settings by adding their own entity attributes for various reasons.
> 
> Finally, some campuses (UCSC most notably) already manage data release by
> adding entity attributes to the metadata through a completely locally
> managed file.

The latter two seem to be the same case. But regardless, the combination of the two cases I don't think is something you could automate today outside of the brute force way of manipulating text to produce the actual bits feeding into Spring.

There's no compositional mechanism except at the higher level of supplying separate MetadataResolvers, which doesn't work when you're trying to load the same metadata in each one, since for any given lookup, one's going to trump the other, order aside.

I think what you need is what we didn't implement (unless Rod corrects me), a way to externally define a MetadataFilter and inject that into an existing resolver, possibly across files.

If it wasn't for all the custom XML heritage, this would just be done in Spring natively and it would all work. And I suppose if you did it all by hand, you could make it work. There's nothing preventing you from hand-wiring up all the classes involved with Spring. We just don't have a hook to mix and match the approaches in this case, and doing all of the wiring for every bit of the metadata resolver is probably not very fun.

> Jeffrey is working on configuring this, and the three files he listed each map
> to one the purposes listed above, and the intended functionality also
> explains the questions about "precedence".

Right, but I wasn't clear what was in the files proposed (and I'm still not, I'm just assuming).

> So stepping back from the specific technical question Jeffrey asked, the
> problem we are trying to solve is having multiple filters files -- at least one of
> which is remote -- being processed against the one metadata source. It
> sounds from your comments like we might be better off building a process to
> fetch and just "cat >>"  the two (or three) files together (taking ordering into
> consideration) and then use the resulting file as the single filter for the
> resource. But honestly we're flexible about the actual approach.

AFAIK, that's the only way you could do it today, or the alternative of actually custom-building your own new MetadataFilter itself, which would e.g. configure itself using remote input, essentially solving the problem from the inside within the existing system's constraints. But that's not super-fun, not so much because the Java part is hard, but because getting that plugged in requires doing custom XML work and writing a Spring parser, like all the old V2 plugins required.

So there are a few options, none great, all taking some work, and nothing plug and play unless we extend the schema, which I'm sure we can do, but it wouldn't be there until 3.3.

-- Scott