Same -- that is the question. Is it going to be annoying to register these things? We don't know yet. So I suppose, let's stop worrying about it.<br><br>Pete does raise a good point, though. These classes are in the IMPL, not the API, and will not be visible in the JavaDocs where they should be.<br>
<br>How do we address that?<br><br>--Lincoln<br><br><div class="gmail_quote">On Mon, Apr 19, 2010 at 12:03 PM, Dan Allen <span dir="ltr"><<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div class="im">On Mon, Apr 19, 2010 at 11:50 AM, Pete Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com" target="_blank">pmuir@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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?<br>
<br>
Because otherwise, I don't have a clue how putting something in this special intercept package can magically stop people refactoring... If I have<br>
<br>
org.jboss.seam.intercept.ConversationBoundaryInterceptor<br>
<br>
and someone renames it to<br>
<br>
org.jboss.seam.intercept.ConversationEdgeInterceptor<br>
<br>
it's just as broken for users...<br>
<div><div></div><div><br></div></div></blockquote></div><div>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).</div>
<div><br></div><div>If there is a refactoring, it must preserve backwards compatibility through delegation (Seam 2 did this to prevent similar breakage in configuration files).</div><div><br></div><div>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.</div>
<div><br></div><font color="#888888"><div>-Dan</div><div> </div></font></div><div><div></div><div class="h5">-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br>
<br><a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br>
<a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen" target="_blank">http://www.google.com/profiles/dan.j.allen</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com">http://ocpsoft.com</a><br><a href="http://scrumshark.com">http://scrumshark.com</a><br>"Keep it Simple"<br>