Quick thought about XML vs annotations for Spring wiring

[Brent Putman]

On 9/21/15 11:23 AM, Cantor, Scott wrote:
> On 9/21/15, 11:12 AM, "dev on behalf of Tom Zeller" <dev-bounces at shibboleth.net on behalf of tzeller at dragonacea.biz> wrote:
>
>> On the last dev call, we talked about whether we preferred XML (i.e. a Servlet) or annotations (i.e. a @Controller).
> I don't think XML implies a servlet. 

Yes.  And indeed a servlet doesn't imply XML.  As of Servlet spec 3.0+,
with appropriate container support, you can "wire" servlets, filters,
listeners, etc without touching web.xml using @WebServlet, @WebFilter,
@WebListener, etc.


> It just implies a separation of the code from the declaration, which I prefer, but that's a personal view. I would (as the author of an extension) always favor explicitly configuring a mapping of paths to methods over annotations any day because one is hardcoded and one is configurable, and hardcoded paths are always a problem eventually.

I may have implied differently on the last call, but for a
product/project like Shib, intended to be deployed by many people with
many use cases and config needs, I also think explicit, override-able
config is desirable and necessary.  Hardcoded paths (e.g. in
annotations) are in general probably not a good idea for that use, I think.

On the other hand, for my local projects where it's just me/GU, then
the (practically) effortless ease of use of annotations often outweighs
the downsides for many things like Spring MVC.  Since I know I won't
need to change or re-map paths.  Or if I do, it's my code and there's
just one deployment of it, so there's no concern.

> I'm not taking a position on it so long as there's no bleed-over. I
> didn't know the scanning was package-specific. 

It is, like this if configuring the scanning via XML wiring (see below
for other way):

<context:component-scan base-package="org.example.foo,
edu.somewhere.bar" />


When I mentioned on the call, I was originally thinking that the value
for base-package could just be a property we could expose in
idp.properties or something.  But just now I see this in the XML docs
for <context:component-scan>:

Note: You may use placeholders in package paths, but only resolved
against system
properties (analogous to resource paths). A component scan results in
new bean definition
being registered; Spring's PropertyPlaceholderConfigurer will apply to
those bean
definitions just like to regular bean definitions, but it won't apply
to the component
scan settings themselves.


I haven't tested, but if it works like I'm reading it, only system
props would work.  I have no idea why they would have that limitation.

If so, I'm sure there's ways to work around, like just having a plugin
declare its own element in an XML file that is included - if you can
have multiple <context:component-scan> elements.  If not, then perhaps
just a single one in user-space config that is used.

*******

Also: The original subject was "XML vs annotations for Spring wiring",
but there's also a third category here (which also uses annotations, in
a different way) and that's the newer Java config stuff.  Meaning a
class or classes annotated with @Configuration which produce beans via
@Bean methods.  Component scanning can also be configured via that
mechanism - via @ComponentScan - as can most everything else that we
typically do via XML wiring.

I bring it up b/c Spring Java config can co-exist with wiring which is
bootstrapped via XML (and vice-versa).  Basically you just point via
the XML wiring at the class(es) annotated with @Configuration.  So if a
plugin wanted to wire its beans that way, in theory it could.  And I
think we wouldn't care about that either.


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