[seam-dev] Interceptor packaging convention

[Pete Muir]

On 16 Apr 2010, at 20:19, Lincoln Baxter, III wrote:

> Ugh, though using this package convention means that hiding classes via package-private is less appealing.

It also goes against all guidelines for designing modular software, and will make adopting either Jigsaw or OSGi much harder.

Watch a presentation on either for why :-)

> 
> On Fri, Apr 16, 2010 at 3:17 PM, Lincoln Baxter, III <lincolnbaxter at gmail.com> wrote:
> I should add that I'm fine with using whatever packaging schema the Interceptor would reside in without such a convention, but this protects us from refactoring, so I think it's a good idea.

I don't understand how this "protects us from refactoring" - can you explain what you mean?

> 
> --Lincoln
> 
> 
> On Fri, Apr 16, 2010 at 3:16 PM, Lincoln Baxter, III <lincolnbaxter at gmail.com> wrote:
> Ok - so this means we are back to square one. Can we discuss and agree on the following guidelines?
> 
> 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

> 	• Warn users (or Error out when appropriate) if they are using interceptable @Annotations when the @Inteceptor itself is not registered, and provide instructions to correct the configuration:
> 
> (@Interceptor registration can be checked in the Extension class AfterBeanDiscovery via BeanManager.resolveInterceptors(type, interceptorBindings)

Yes. We need a util method for this.

> All @Decorator classes must:
> 	• Adhere to the following package and naming scheme: org.jboss.seam.decorate.*Decorator

As above.

> Let's discuss and resolve, since we're starting to release, and this is important. (Affects Faces directly.)

This is all in the guidelines already...