Quick thought about XML vs annotations for Spring wiring

[Brent Putman]

On 9/24/15 1:28 PM, Cantor, Scott wrote:
> 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".

Ok, but I assume you mean "override" beans from a higher context in a
lower context.  Since IIRC Spring enforces ID uniqueness at the XML
level (at least I think the bean ID is an XML ID type).  Although I
guess there's also 'name' aliases - don't know what it does with
duplicates names there...
>
>> 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. 
Actually, I wasn't trying to oppose my "clean" with your "not clean",
different train of thought...


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

... but point taken.  Yes, you can't "take away" beans that are there,
and if they are being picked up by post-processors based on annotations
or implemented interface, etc (how the MVC and some other built-in
Spring stuff does), then I agree there's a problem.

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

I guess I haven't looked but I thought we had a user-space config way
for users to add stuff to web.xml that carries across upgrades.  Maybe
I'm misremembering.  Or we talked about but didn't implement?

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


All true.  In my (anal retentive) mind, I think of the MVC
ApplicationContext as only for MVC (and SWF) related stuff, not for
application beans, etc.  So that's the very stuff you want to be
different.  If there are application beans there, then yes of course,
you can't get at them from a sibling context.  My thought would simply
be: don't do that.  We tend not to do that ourselves, as you said, so I
don't see a problem with this aspect.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150924/ece97083/attachment.html>