Re: [seam-dev] Interceptor packaging convention
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).
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
Attachments:
- attachment.html (text/html — 2.3 KB)