Changes to web flow action proposal

[Cantor, Scott]

On 4/20/13 12:43 AM, "Brent Putman" <putmanb at georgetown.edu> wrote:

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

Ok, I didn't see that mantioned and they kind of dribble out definitions
of syntax in the docs.

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

That limits what it considers for injection, but not what it looks at to
inject into. So once you turn an autowiring setting on globally, it looks
at every property of a given name or type on every bean for possibly
injection. The limiting then reduces the pool of candidate beans to
prevent ambiguity.

>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

Yes, I'm fairly certain it's not the best way.

-- Scott