Agreed, the interceptor is definitely part of the public API - they have to reference the
class in their beans.xml.
Having it in the javadoc is no replacement for a decent ref guide, but can be useful for
some IMO.
On 20 Apr 2010, at 03:02, Lincoln Baxter, III wrote:
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(a)lists.jboss.org
>
https://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
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev