They still have to put it in their beans.xml file in order to enable it;
that means they need to know the fully qualified class name :(
On Mon, Apr 19, 2010 at 6:01 PM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
On 20/04/10 02:03, Dan Allen wrote:
On Mon, Apr 19, 2010 at 11:50 AM, Pete Muir <pmuir(a)redhat.com> wrote:
> Ok. I *think* I might get what you are talking about now - you are
> concerned because the interceptor has to go into the impl/ jar, not the API
> jar? And that therefore developers are going to forget that it is actually
> part of the public API? Or?
>
> Because otherwise, I don't have a clue how putting something in this
> special intercept package can magically stop people refactoring... If I have
>
> org.jboss.seam.intercept.ConversationBoundaryInterceptor
>
> and someone renames it to
>
> org.jboss.seam.intercept.ConversationEdgeInterceptor
>
> it's just as broken for users...
>
> That's a great point and now I see this so clearly. Interceptors must
be considered part of the public API and a stable API is expected not to
shift (for backwards compatibility reasons). It's public API because the
develop must refer to the interceptors in beans.xml (according to spec,
putting workarounds aside).
I don't really see it as part of the API - the user never imports the
class, never refers to it in any code. The one place where this might be
relevant is the API Javadoc, which the user might possibly be using as their
reference. I don't think that Javadoc is the right place for a user to be
going though to understand how to use any particular library, especially in
our case with the high standards we have for reference documentation.
If there is a refactoring, it must preserve backwards compatibility
through delegation (Seam 2 did this to prevent similar breakage in
configuration files).
So I guess the real issue at hand is...the consistent packaging of
interceptors is really about making the <interceptors> element as simple as
possible by making all the interceptors classes have the same number of
package segments. That need may or may not be contrived. I haven't stood in
the shoes of the developer yet being required to list out a bunch of
interceptor classes.
-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
_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev