Quick thought about XML vs annotations for Spring wiring

[Cantor, Scott]

On 9/24/15, 1:16 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:

>I'm not totally sure what is meant here by "bean overrides", or what the use case(s) are.  I agree with Scott that it sounds brittle.

Meaning declaring beans with the same ID so that a given one "wins".

>But underlying that: someone may in theory need an MVC config which is "clean", i.e. not polluted with our stuff, and/or they can't add their stuff without breaking ours.

What I meant by "not clean" was their config design, not the content. They use a random pile of top level beans sitting in the context to figure out what to do. "Clean" would be a list of beans for some function such that I can override that list if desired. With their approach, once a bean gets declared in the context it's not something one can just "mask". At least it doesn't appear that way to me.

>  That was the reason I suggested some cases may want to use a separate distinct DispatcherServlet
> - it gets its own config and ApplicationContext.  I don't necessarily think we should wire an empty one apriori.  But if a deployer or extension wants to modify web.xml, they can add their own, so just noting it for the record.

Clearly, yes. But I know we will need to make ongoing adjustments to web.xml, so the less it's used for extensions the better IMHO.

>(Because of the sound dropping
> out, I still don't think I ever heard on the call what Misagh's concerns with this were.  Other than needing be mindful of the ApplicationContext hierarchy, I can't off-hand think of any problems with this. But I'd welcome discussing any potential problems.
> )  

I think it was just the fact that once you end up with sibling contxts, there's no easy access to their beans. I don't know that I think that's a big deal though since our beans are mostly either global/root, or in specific service facades now.

-- Scott