A note about the (reloading) services for RelyingParty.xml

[Rod Widdowson]

I've started coding these up and hope to have them done reasonably soon.

I'd like to highlight one implication of the implementation - that the
resolved objects in the object tree returned from the resolution process
should be perfectly detached from the resolvers or, if they are not, then
they should not do any work during #destroy()/#doDestroy() - 

The reason of course is that, whilst the resolution process is
lock-protected, the service may encounter a need to reload the resolver
while the resolved objects are use and will issue an asynchronous destroy on
the resolver (which will of course destroy any objects loaded by the same
Spring context).  

In the attribute service case the resolvers are destroyed, but the output of
the resolution process (the attributes) are fully detached.  In the case of
the contents of the relyingParty this is not true (for instance inline
metadata, or credentials).  So we have to rely on these objects not
implementing destroy.

I believe that we are currently OK since the resolved objects are simple and
need to special teardown (as opposed to the resolvers which are heavyweight
and can get torn down, but are protected by locks).

Further I should note that the reloading metadata resolver have to work
under similar constraints and always have done, but this does make me
slightly nervous.  Hence this mail:

For the record the alternative make me much more nervous and include:

1) Clone the result of the resolution process.  This one worries me because
ISTR that cloning on an XMLObject (which is what is returned from metadata
resolution) involves serializing out to the DOM and back.  I'd imagine that
cloning a Credential would be similarly unpleasant, not to mention all the
code we would need to add (and test and support).

2) Keeping the metadata lock for as long as we require the result to be
valid.  Given our architecture I believe that this would be extra-ordinarily
foolhardy.

Just FYI

/Rod