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

[Cantor, Scott]

On 4/21/14, 8:04 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>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() -

Yeah, which should have also been true in V2 but I felt like all of this
was implicit and not clearly spelled out.

>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.

It does. I implemented cloning everywhere on the actual objects, but the
Java version didn't.

In terms of overhead, actually cloning the specific EntityDescriptor would
not be that expensive, but we don't have code to do it, and we're hanging
key material off the objects now also, which would be another problem to
clone.

>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.

Yes, we store the metadata objects in the context tree, but the locking is
done by the actions. We would have to basically alter things and look up
the metadata in real time in each action that used it.

-- Scott