Re: [seam-dev] Interceptor packaging convention

Referring to protection from refactoring: • We have a class in: org.jboss.seam.faces.context.conversation.ConversationBoundaryInterceptor Three months later, we do some refactoring, and that interceptor moves (because it doesn't really matter where it lives, as long as it is enabled -- again, this problem would be solved by some sort of automatic enabling and ordering.) • The class is now in: org.jboss.seam.faces.conversation.ConversationBoundaryInterceptor We just broke all of our existing users -- now, this is of course easy to prevent: don't move the class, but it is a concern that could lead to code fragility and brittleness. --Lincoln On Mon, Apr 19, 2010 at 11:22 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: On Mon, Apr 19, 2010 at 5:48 AM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > All @Interceptor classes must: > • Adhere to the following package and naming scheme: org.jboss.seam.intercept.*Interceptor No, why would we want to do this? Classes defined in a module should reside in a package owned by that package. It prevents any risk of namespace clashes Referring back to Lincoln's suggestion, I though we were using org.jboss.seam.{module}.intercept.*Interceptor? That would make them easier to locate in the API docs yet still reside in a package owned by the module. I just worry that if we scatter interceptors (and decorators) further down in the packaging of a module, it will be harder to enforce consistency from one module to the next. Is that a reasonable convention? -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"