Quick thought about XML vs annotations for Spring wiring
Brent Putman
putmanb at georgetown.edu
Thu Sep 24 13:16:19 EDT 2015
On 9/24/15 12:41 PM, Cantor, Scott wrote:
> On 9/24/15, 10:34 AM, "dev on behalf of Misagh Moayyed" <dev-bounces at shibboleth.net on behalf of mmoayyed at unicon.net> wrote:
>> Given the current IdP config architecture, I'd be inclined to
>> simply include a template XML config file that is totally empty, into the
>> context which is then decorated with all the right spring namespaces.
>>
>>
>>
> We mostly do but the MVC and webflow files are being loaded by the IdP servlet context and not globally, which I forgot, so we're missing an include.
Yeah, that was my conclusion as well. We should have e.g.
mvc-beans.xml include a file from user-space config, like
global-system.xml include global.xml Or else just modify the
DispatcherServlet in web.xml to include a specific user-space file,
initially empty.
>
> I'm not too keen on relying on bean overrides, though, just feels brittle. Some of that's unavoidable because MVC config isn't that clean, but for most of our components we use other techniques to handle it.
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.
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. 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. (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. )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150924/f99cc96f/attachment.html>
More information about the dev
mailing list