Native Spring Integration

[Cantor, Scott]

On 4/30/14, 3:42 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>Thusfar we have use the class of the bean to do the wiring (query the
>setters find what they are looking for, look for one of these), this works
>very nicely and it is my plan for integrating the SecurityConfiguration,
>but
>this will fall apart if we want to start putting in multiple plugins of
>the
>same class.

That's inevitable I'm afraid.

>Allowing customization of the crypto predicates means that there will be
>up
>to 6 objects of class Predicates which can be injected.  SSOSProfile adds
>a
>7th.

Yes, my whole idea was to use Predicate<ProfileRequestContext> universally
so that everything would be interchangeable across subsystems (e.g. a
predicate based on entityID, based on entity attributes, etc.)

Eventually probably extend this back into the attribute filter someday to
get rid of that special code.

>This is pretty tempting, but it would mean that we could not use property
>replacement there.  I don't think that I had thought about this until now,
>but property replacement is pretty much incompatible with bean references,
>so if something can be used as a value or a reference (as here) we cannot
>also use property replacement.

That's a damn shame. I'm not sure it's a bad trade off though because the
substitute for properties there becomes just supplying your own beans file
anyway, but I admit the inconsistency would be a nightmare.

>So we have to use names.  We can use fixed bean names or allow the
>specification of a bean name as an attribute.  My preference is for the
>former but I have no strong feelings.  Either way there is a documentation
>load.

I'm not sure fixed names can work, because what would the name be across
different elements that are the same (e.g. different RelyingParty
elements)?

-- Scott