Re: [seam-dev] Interceptor packaging convention
On 19 Apr 2010, at 16:22, Dan Allen 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?
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.