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> wrote:
On Mon, Apr 19, 2010 at 5:48 AM, Pete Muir <pmuir(a)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"
Attachments:
- attachment.html (text/html — 2.8 KB)