Changes to web flow action proposal

[Brent Putman]

On 4/20/13 6:51 AM, Ian Young wrote:
> On 20 Apr 2013, at 05:43, Brent Putman <putmanb at georgetown.edu> wrote:
>
>> 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
> Sounds like a positive direction to me.  I looked into this for another activity a while back, and came to the conclusion that autowiring was a bit broad brush and intended for some specific use cases I didn't have.  

Autowiring might ultimately be a bit broad for what we want to do, although I think that the
candidate list makes that at least a little more palatable for cases where it makes sense.


> I'm also now fairly nervous about anything that goes in at the <beans> level because the question of when things apply to the context and when just to the specific configuration file seems fairly opaque and has lead to some surprises, for me at least.

Hmm, yeah, I hadn't thought about that.  My intuition would be that the resulting context doesn't
know about the file boundaries, if there are multiple files, so the <beans> settings would be
merged, with last one (or first one) wins, or something like that.  Did you see something
different?  I haven't had a chance yet to play around with any of this yet, but I'll add that to the
list.

>
> I make heavy use of bean definition inheritance in the UKf MDA deployment, and it seems to work pretty well for this kind of thing.  There are, again, some surprises around the area of which things are inherited and which are not but it seems fairly usable.

Ok, good to know.  If you mean around which bean definition properties are "inheritable", yes, there
are some rules for that, they're in the docs.  What they do didn't seem strange to me at least when
I was reading it.


>
> BeanPostProcessor beans seemed like they would really simplify things, but I didn't actually get round to trying it. 

Yes, those have the nice property of being semi-automagical but also targeted, without the broadness
of auto-wiring, at least for this use case.  Writing those would seem to be pretty simple also.


>  The other thing available seemed to be the equivalent at the factory level, which allow you to alter the bean definitions rather than the beans themselves; did you look at that at all?

Yes, I did look at the BeanFactoryPostProcessor.  It seems interesting as well.

The other main interesting thing, previously unknown to me, was the Java-based config stuff, which
used to be a separate project and is now in Spring core.

I'm going to do a braindump into a wiki page, I'll send out when done.