Native Spring Integration

[Rod Widdowson]

In another thread Scott said:

> Well, that setting itself will be deprecated in favor of a predicate, and
> my intention was we'd treat the old setting as a trigger to install the
> legacy predicate. 

That raises the issue of communication between the native embedded context
and the legacy parsers.  

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.

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.

> Alternatively, we could overload the setting itself and,
> now that it's a string type, we could use it to either carry the old
> values or a bean-ref.

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.

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.

A related issue is the scope in which to look for the beans.  My instinct is
probably to limit this to the embedded native code since it makes it
possible to determine whether to use defaults or not purely by the presence
of a bean of that name.    Indeed I'm, not sure (I'll need to try and see)
what would happen if one tried to resolve a in the current context while one
was still parsing into it.

Rod