Quick thought about XML vs annotations for Spring wiring

Brent Putman putmanb at georgetown.edu
Thu Sep 24 14:18:40 EDT 2015



On 9/24/15 2:04 PM, Cantor, Scott wrote:
> Aliases get around that, but so does using separate files. The XML ID thing is optional and only works within a single file. With included XML files they can collide and people view it as a feature. I think it's a risky thing to take advantage of, and would argue it's better to templatize the actual name of the bean being injected and just override that.

Ah, ok.  I was ignoring the separate files case.  Yes, I think that
would be brittle.    I assume by "templatize" you mean use a property
that can be configured.  That works.  So also would be to alias the
bean using an actual Spring <alias /> element - peg the actual injected
bean ID to the alias and let people change what the <alias/> points at,
to override.  I agree those would be better solutions.  I personally
wouldn't want to rely on the order of evaluation of the bean XML files,
or however that's working.
 

>> 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?
> We have a way to edit it and get it used in place of the delivered file, but that's it. If we *have* to change it, that makes upgrades troublesome, so editing it is not a step to take lightly as a deployer.

I see.

>
> I realize that there are web.xml overlays now, but we didn't try those. They're relatively new.


I guess there's several similar things that do something like that. 
Maven has their war overlay stuff, which I personally haven't used. 
Jetty has their override mechanism which allows you to add stuff, which
I have used.  Works ok, but when I tried it it seemed for certain
things (elements) to be all-or-nothing.   For adding a whole new
DispatcherServlet IIRC it would work fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150924/3e0fbd34/attachment.html>


More information about the dev mailing list