On Wednesday 08 April 2009 10:47:26 Relph,Brian wrote: > Hello, > > I was wondering what the approach was to writing annotation-based > interceptors. I see several interceptors have annotation-based > counterparts (validation), but others do not (roles). Is there a specific > reason for not having annotation-based counterparts for all interceptors? > Or is it mainly that the annotation-based ones have not been requested? I > was about to finalize an annotation-based roles interceptor, but was then > reconsidering, as a change in permissions would require a re-build + > re-deploy if it was annotation based, whereas the original xml-configured > one would require (at the most) a re-deploy. But this argument would also > hold for the annotation-based validation vs. xml validation. > > Thoughts? >
I have a thought on annotations vs. XML. I don't know about your environment, but for me, typically even changes in XML require a full release cycle. The operations guys don't like to take on the liability of making changes to what they consider "code." For my guys, they consider XML to be code, so anything within the WAR file released to them is somewhat considered untouchable. Because of this, I've opted to make my life easier and keep the configuration closer to the affected code, which annotations allows me to do. I'm going to end up constructing a new WAR to give them even if I change an interceptor, result or validation behavior, so I might as well make it easier for me and use annotations. This may not be the case for you, maybe you have more control over production or your SysAdmins have more knowledge of Struts/Spring/WhateverXMLConfiguredLibrary and are willing to make changes. So, it's a matter of preference. -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
