[seam-dev] Interceptor packaging convention

[Lincoln Baxter, III]

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 at redhat.com> wrote:

>  On 20/04/10 02:03, Dan Allen wrote:
>
> On Mon, Apr 19, 2010 at 11:50 AM, Pete Muir <pmuir at 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 at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>


-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100419/7b37c446/attachment-0001.html