Native Spring Integration

[Rod Widdowson]

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

Right, which reminds me of course of the still to be fleshed out need to
have per Attribute resolver predicates.  Once we learn how to do this with
relying-party it should be easy to retrofit to attribute-resolver.
 
> Eventually probably extend this back into the attribute filter someday to
> get rid of that special code.

Right.  I think.
 
>>I don't think that I had thought about this until now,
> >but property replacement is pretty much incompatible with bean
> >references,

I'm not sure that this is true - I'd need to experiment.  However the
consequence

> > if something can be used as a value or a reference (as here) we cannot
> >also use property replacement.

does remain true.  If I have a string called "${something.something}" and I
cannot resolve it as an encryption type I'm going to try to put it in as a
bean of that name (and no I cannot define beans of the three plugin names,
because the whole point of "conditional" is that it is location dependant).

> >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)?

Fixed names would work because the embedded beans file is entirely
encapsulated in its own application context (which has no parent), so the
name can be fixed - if the provided name not defined in the bean file then
that is an error. 

This is quite important and I may have aluded to this elsewhere.   I haven't
looked too hard, but I have yet to work out how to link the Application
Context that we parse the embedded statement with to the Application Context
we are parsing relying party with.  We are not in the right place to have
access to the latter, indeed I would not be surprised if it was impossible.
This of course means that the content of the <spring:beans> statement cannot
reference beans defined elsewhere either.

As an aside: it does not look entirely impossible however to parse the
embedded <spring:beans/> statement into the *same* context that we are
parsing into.  At that point of course fixed names fall apart, as does any
lookup by type since there is no isolation inferred by the <spring:beans/>
statement.  On the other hand we get to play inside the global application
context and have references to other beans.

I'm wondering whether we need to defer this conversation to Friday?

Rod