<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 9/24/15 1:28 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:79513FC2-D16E-4F02-B7D3-5FA18878E120@osu.edu"
type="cite">
<pre wrap="">On 9/24/15, 1:16 PM, "dev on behalf of Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofputmanb@georgetown.edu"><dev-bounces@shibboleth.net on behalf of putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Meaning declaring beans with the same ID so that a given one "wins".</pre>
</blockquote>
<br>
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...<br>
<blockquote cite="mid:79513FC2-D16E-4F02-B7D3-5FA18878E120@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
What I meant by "not clean" was their config design, not the content. </pre>
</blockquote>
Actually, I wasn't trying to oppose my "clean" with your "not
clean", different train of thought...<br>
<br>
<br>
<blockquote cite="mid:79513FC2-D16E-4F02-B7D3-5FA18878E120@osu.edu"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
... 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.<br>
<br>
<blockquote cite="mid:79513FC2-D16E-4F02-B7D3-5FA18878E120@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
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?<br>
<br>
<blockquote cite="mid:79513FC2-D16E-4F02-B7D3-5FA18878E120@osu.edu"
type="cite"><br>
<pre wrap="">
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.</pre>
</blockquote>
<br>
<br>
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.<br>
<br>
</body>
</html>