Ok, I extended AnnotationMethodHandlerAccepter with its exact contents but made more extensible. Then, I extended that with my custom accepter that overrides the invoker with a new one which, in writeWithMessageConverters, enables ioc of read/write executor closures to any inferred implementations of my ReadWriteInjectionHttpMessageConverter. So, I can now detect my custom controller method annotations within the newly extensible handleResponseBody, map closures to specific ReadWriteInjectionHttpMessageConverter implementation types, which get executed on the converter during the writeWithMessageConverters process.

Outcome is I can now bridge any context declared on my custom annotations to the read/writeInternal methods. In my case, I have a @ResponseJsonView annotation on which I define a usecase JsonView that gets automagically applied to the Jackson serialization.

I still have to wonder if there's already a pattern for custom controller annotation plugging-in that I wasn't aware of?

Cheers.

Any easy way to hook in support for custom Spring(v3.0.5) Controller method annotations? I have a usecase for it and am staring at a pretty inaccessible AnnotationMethodHandlerAccepter and its ServletHandlerMethodInvoker implementation.

Very high level, I want to relay a string value from the custom annotation to an ObjectMapper for use by my message converter. Pseudo impl = within invoker.getModelAndView, when findAnnotation(ResponseBody) not null then string custVal = findAnnotation(MyCustAnnot).value, call handleResponseBody(returnVal, webReq, custVal)… and I can also build an appropriate override for writeWithMessageConverters.

Ideally, I wouldn't have to override much but it looks like I need to completely copy and customize AnnotationMethodHandlerAccepter.

Any other way to do this?

Thanks.

SF

Anyway, @Autowired is quite different from traditional autowiring in terms of its implications on manageability of the overall configuration. In contrast to a pure convention (that's what autowiring by name or by type actually is), it specifically applies to annotated fields/methods/constructors only – being free from side effects in that respect (i.e. no accidental mismatch in the use of the convention, leading to too much or too little autowiring).

You have a good point there that annotation-based configuration may lead to better isolation of artifacts, since you won't have to touch "global" configuration files that often anymore.

One point in the article that doesn't really apply anymore is the following: "Remember, with powerful IDEs, such as Eclipse and IntelliJ, Java code is much easier to read, maintain, and manage than XML files!" Well, when using the Spring IDE Eclipse plugin or IntelliJ IDEA 6/7, Spring XML bean definition files are actually pretty convenient to navigate, maintain and manage… Of course, annotations in Java code are even easier maintain. In any case, well-designed XML configuration is still a viable choice as well!

Juergen

At this address http://www.onjava.com/pub/a/onjava/2006/01/25/spring-xml-configuration-best-practices.html, the author discourages autowiring (first point).

I feel he has some poing about being explicit, but on the other hand Spring autowiring will always load the implementation you think since if it finds two candidates (without any @Qualifier) it will just stop.

OTOH, in our case, using annotations&autowiring would reduce the risk of collisions between context files modifications. In fact, we already have more than one context file, but we still find ourselves modifying the same file and having to merge. With annotations-based config, the isolation would be better I think.

I know this article is now a bit old, but I'd be very interested to know what you think about it.
Maybe even what you
- *thought* about it if you already knew about it before ?
- and maybe which new Spring feature you'd think would deprecate some of the article's statements (mainly about autowiring btw, but also for some other points) ?

Thanks and Cheers.

You do have a point, of course. For true separation of concerns, externalized metadata (such as XML) is the better choice – and still a first-class choice in Spring 2.5. We just give people more choice now, while we historically more or less enforced externalized configuration.

Note that annotations that you use in your application classes do *not* have to present in the classpath for loading those classes. At least for recent JDK versions, non-present annotations will simply be ignored when loading your class. This arguably makes it more acceptable to embed Spring-specific annotations. And of course, with respect to the JSR 250 and JPA annotations: Those aren't Spring-specific in the first place, so shouldn't cause as much concern.

Overall, Spring still aims to provide the most comprehensive XML component metadata format around: very flexible but also as concise as possible (given the fact of externalization to begin with). This will always remain a key differentiator between Spring and other solutions.

Juergen

Regardless of the usefulness of the various Spring annotations, I feel that annotations (Spring's or any other framework's for that matter) introduce a dependency on that particular framework/technology.

In my opinion, an annotated POJO (e.g. Spring's @Transactional annotation) is no longer a POJO, don't you think?

For instance, if I want to reuse parts of my domain-model in another application, which does not use Spring, I still need to include the Spring jars in that application's classpath, don't I?

In its early days Spring used to advocate non-intrusiveness, and that was a principal differentiator between Spring and EJBs. Now, it seems to me that as Spring offers more and more annotations (which, again, are very useful) domain-specific code becomes more and more dependent on the Spring framework. I realize many people find XML configuration un-cool, but I think at least that way true separation of concerns is maintained.

I am not trying to be polemic. I am really very interested in your thoughts on this.

Thanks,
Naaman