Referring to protection from refactoring:
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.)
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@gmail.com> wrote:
On Mon, Apr 19, 2010 at 5:48 AM, Pete Muir <pmuir@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"