[seam-dev] Interceptor packaging convention

[Pete Muir]

Ok. I *think* I might get what you are talking about now - you are concerned because the interceptor has to go into the impl/ jar, not the API jar? And that therefore developers are going to forget that it is actually part of the public API? Or?

Because otherwise, I don't have a clue how putting something in this special intercept package can magically stop people refactoring... If I have 

org.jboss.seam.intercept.ConversationBoundaryInterceptor

and someone renames it to

org.jboss.seam.intercept.ConversationEdgeInterceptor

it's just as broken for users...

On 19 Apr 2010, at 16:43, Lincoln Baxter, III wrote:

> 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 at gmail.com> wrote:
> On Mon, Apr 19, 2010 at 5:48 AM, Pete Muir <pmuir at redhat.com> 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"