[seam-dev] Interceptor packaging convention

[Lincoln Baxter, III]

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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100419/314d7e1a/attachment-0001.html