Multiple input files to the service (separated from RE: idpv3 first look)

[Rod Widdowson]

Taking this into a separate thread.

> Oh, I bet the custom parsing is building a service instance around every
> individual file. 

Kinda - in fact it’s the AttributeFilterPolicyGroup (AFPG) which is parsed
into a ServiceableComponent (which also implements AttributeFIlter).  That’s
pretty much standard for all the top level custom parsed components.

> Hmm, not sure what we'll do there, Rod what do you think?

I'll need to ponder this some more.  Off the top of my head there's no easy
solution because of the way the plumbing works.

Specifically we need to be able to extract all ApplicationFilterPolicy
elements from the (spring) ApplicationContext and then summon that up into
the ServiceableComponent.  The current code does the extraction from the dom
for the specific AFPG (rather than the application context of all the
resources).

Currently the service code is completely neutral with respect to what is in
the ApplicationContext - it just needs to have single ServiceableComponent
available of the right type.  
I guess we could abstract that code out into a Function and inject that
rather, than the Class, into ReloadableSpringComponent.  Then this Function
could do the work that the AFPG parser does an summon up the correct sort of
component.  

I'll should note that this is, in fact, flattening the AFPG out of the
system and saying "Build me a filter which contains all the
AttributeFilterPolicy rules in the files I specify", whereas before the
grouping was explicit in the AFPG;  I'm not sure that this is a correct
thing to do, although I completely see what Jim is trying to achieve.

Slightly related to all this is the not-yet-functional, but probably
fixable, issue of Rule references.    If we got them going and also added
references for AttributeFilterPolicy we could achieve much the same by
bracketing the contents of the second file in a <beans> element rather than
a <AFPG>

/R