<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 9/21/15 11:23 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:FFF24E5B-2723-4F72-9E11-381FF90EB818@osu.edu"
type="cite">
<pre wrap="">On 9/21/15, 11:12 AM, "dev on behalf of Tom Zeller" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfoftzeller@dragonacea.biz"><dev-bounces@shibboleth.net on behalf of tzeller@dragonacea.biz></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On the last dev call, we talked about whether we preferred XML (i.e. a Servlet) or annotations (i.e. a @Controller).
</pre>
</blockquote>
<pre wrap="">
I don't think XML implies a servlet. </pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote cite="mid:FFF24E5B-2723-4F72-9E11-381FF90EB818@osu.edu"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote cite="mid:FFF24E5B-2723-4F72-9E11-381FF90EB818@osu.edu"
type="cite">
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.
</blockquote>
<br>
It is, like this if configuring the scanning via XML wiring (see
below for other way):<br>
<br>
<tt><context:component-scan base-package="org.example.foo,
edu.somewhere.bar" /></tt><br>
<br>
<br>
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 <tt><context:component-scan>:<br>
<br>
Note: You may use placeholders in package paths, but only resolved
against system<br>
properties (analogous to resource paths). A component scan results
in new bean definition<br>
being registered; Spring's PropertyPlaceholderConfigurer will
apply to those bean<br>
definitions just like to regular bean definitions, but it won't
apply to the component<br>
scan settings themselves.<br>
<br>
<br>
</tt>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.<br>
<br>
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 <tt><context:component-scan></tt>
elements. If not, then perhaps just a single one in user-space
config that is used.<br>
<br>
*******<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
</body>
</html>