Changes to web flow action proposal

[Brent Putman]

On 4/19/13 2:51 PM, Cantor, Scott wrote:

> Was looking at the auto-wiring stuff a little. There's no way to do
> something non-invasive to every bean definition because the autowrire
> attribute defaults off. Also seems to be a little invasive in that it will
> try to autowire all your properties, maybe it's more constraining to just
> do "constructor" and limit it to constructor argument injection.

I've been spending some time today reviewing Spring stuff, focusing on some of the non-basic things
that we've never used.  I'll send out something probably tomorrow with a summary of ideas, etc, but
on autowiring specifically:

You can set the autowiring for the whole Spring ApplicationContext on the <beans> element with the
'default-autowire' attribute.  Takes the same values as the <bean> 'autowire' attribute.  This I
already knew.

What I didn't know was:  There's some ways to influence the selection of autowire candidates.  What
seems particularly useful for us might be the <beans> 'default-autowire-candidates' attribute, which
takes a comma-separated list of regexes to match against bean name id/name.  Only those that match
will be candidates for autowiring into other beans.  So if in the Spring context we only wanted to
autowire the ProfileRequestContext, I think we could do something like this:

<beans default-autowire="byType" default-autowire-candidates="shibboleth\.ProfileRequestContext" ... />

or even declare a bean "namespace" for auto-wired things + a regex wildcard:

<beans default-autowire="byType" default-autowire-candidates="shibboleth\.autowired\.*" ... />

I haven't tested yet, but that's what the docs say.


Having said all that though... Autowiring isn't necessarily the best way to solve the concerns we
were discussing today with respect to wiring the contexts and/or requests/responses: cleaning up the
beans file, reducing noise, etc.  Details later, but the advance preview is (at least): 1) bean
definition inheritance 2) BeanPostProcessors