[seam-dev] Interceptor packaging convention

[Pete Muir]

On 19 Apr 2010, at 16:22, Dan Allen 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?

Not really IMO.

Personally, I find the convention of putting an interceptor into a package called .intercept. rather cumbersome for a user. Where has this requirement come from? I feel like I am missing the beginning of some discussion where the benefits of this approach were discussed (actually, AFAIK we've already agreed on the points I am making - http://lists.jboss.org/pipermail/seam-dev/2010-April/002303.html)

It's much better to organize the API along functional lines. Collect all the elements of the API that form a coherent whole into (sub) package.

For example, to take the Security module, how is it better to structure the module like:

org.jboss.seam.security
   .qualify.
   .intercept.
   .decorate.
   .alternate.

than

org.jboss.seam.security.
   .identity.
      .jpa
      .ldap
   .authorization.
   .authentication.

I find the latter much clearer. It allows me to browse a package using any tool, including the command line, and see what options I have to solve my problem (rather than understand up front what sort of thing I might want to use to solve my problem). This is especially true if you are already calling your interceptor BlahInterceptor.