<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">+1 for that.<br><br>Even if you have 10 interceptors (or more) in a project, only few of them will get used on the same class at a time. And even in this rare cases, in 95% the ordering will make absolutely no difference at all.<br><br>Also I cannot read this restriction from the spec, please point me to the location.<br><br>IF there is any ordering needed, those interceptors have to be defined in the same beans.xml. <br><br>So an algorithm like the following is imo enough:<br><br>if (beans.xml contains <interceptors>) {<br> if (interceptors.size() > 1) {<br> removeInterceptorsIfAlreadyDefined(interceptors);<br> addInterceptors(interceptors); //make sure they are now in the right order<br> } else {<br> addInterceptorIfNotYetDefined(interceptor);<br> }<br>} <br><br>or something like
that.<br><br>This would remove most of the problems. The only problematic situation remains if 2 beans.xmls defines a different ordering for the same interceptors.<br><br>LieGrue,<br>strub<br><br>--- Shane Bryzak <i><sbryzak@redhat.com></i> schrieb am <b>Fr, 26.3.2010:<br></b><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><b><br>Von: Shane Bryzak <sbryzak@redhat.com><br>Betreff: Re: [seam-dev] Interceptor packaging convention<br>An: "Lincoln Baxter, III" <lincolnbaxter@gmail.com><br>CC: "Seam Dev List" <seam-dev@lists.jboss.org><br>Datum: Freitag, 26. März, 2010 01:27 Uhr<br><br></b><div id="yiv1208239308">
<b>
This will be a major inconvenience for our users if we expect them to
manually add all the interceptors they need for conversations,
security, transactions, and who knows what else. Is there absolutely
no other way that we can automatically register these in the
extension? Also I'm not a big fan of having to use the
org.jboss.seam.intercept namespace, I don't want to have to include a
lone class in this package if all my other classes are in (for example
the security module) org.jboss.seam.security.<br>
<br>
On 26/03/10 10:14, Lincoln Baxter, III wrote:
</b><blockquote type="cite"><b>Seam Devs,<br>
<br>
Dan and I have been working on the @Begin and @End conversation support
for Seam Faces, and we've discovered that there is a new fact of life
for consumers of portable CDI extensions. Due to the fact that
@Interceptors cannot be enabled in the extensions themselves (due to
restrictions on beans.xml for purposes of absolute ordering in the
application. See: <a rel="nofollow" target="_blank" href="http://seamframework.org/Community/EnablingAnInterceptorInALibrary">http://seamframework.org/Community/EnablingAnInterceptorInALibrary</a>
)<br>
<br>
This presents an interesting issue; we want to be providing a good
out-of-box experience, but interceptors must be registered manually.<br>
<br>
This means that @Interceptor classes must be:<br>
</b><ul>
<b> </b><li><b>Exposed to the developer</b></li>
<b> </b><li><b>Registered manually by the developer in beans.xml -
<interceptors>...</interceptors><br>
</b></li>
<b> </b><li><b>Consistently named and packaged to prevent refactoring /
backwards compatibility issues</b></li>
<b> </b><li><b>Checked at startup in order to warn devs that they are using
annotations with no enabled @Interceptor<br>
</b></li>
<b> </b></ul>
<b>We would like to propose the following conventions in order to address
the above concerns:<br>
<br>
All @Interceptor classes must:<br>
</b><ol>
<b> </b><li><b>Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor<br>
</b></li>
<b> </b><li><b>Warn users (or Error out when appropriate) if they are using
interceptable @Annotations when the @Inteceptor itself is not
registered:<br>
(@Interceptor registration can be checked in the Extension class
AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
interceptorBindings)<br>
</b></li>
<b> </b></ol>
<b>This presents users with:<br>
</b><ol>
<b> </b><li><b>A consistent naming scheme to help prevent typos.</b></li>
<b> </b><li><b>A safety net to catch them when they fall down (because we
forgot to tie the ladder.)</b></li>
<b> </b><li><b>A protected namespace so that when we refactor, we don't break
their world. (Even though #2 would catch it.)<br>
</b></li>
<b> </b></ol>
<b>I've updated the <a rel="nofollow" target="_blank" href="http://seamframework.org/Seam3/DevelopmentGuidelines">Seam 3 Development Guidelines</a> to reflect these
conventions - they can be changed as needed pending the outcome of this
discussion :)<br>
<br>
-- <br>
Lincoln Baxter, III<br>
<a rel="nofollow" target="_blank" href="http://ocpsoft.com">http://ocpsoft.com</a><br>
<a rel="nofollow" target="_blank" href="http://scrumshark.com">http://scrumshark.com</a><br>
"Keep it Simple"<br>
</b><pre><fieldset class="mimeAttachmentHeader"></fieldset><br><b>_______________________________________________<br>seam-dev mailing list<br><a rel="nofollow" class="moz-txt-link-abbreviated" ymailto="mailto:seam-dev@lists.jboss.org" target="_blank" href="/mc/compose?to=seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br><a rel="nofollow" class="moz-txt-link-freetext" target="_blank" href="https://lists.jboss.org/mailman/listinfo/seam-dev">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br> </b></pre>
</blockquote>
<b><br>
</b></div><b><br>-----Integrierter Anhang folgt-----<br><br></b><div class="plainMail"><b>_______________________________________________<br>seam-dev mailing list<br><a ymailto="mailto:seam-dev@lists.jboss.org" href="/mc/compose?to=seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/seam-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/seam-dev</a><br></b></div></blockquote></td></tr></table><br>__________________________________________________<br>Do You Yahoo!?<br>Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. <br>http://mail.yahoo.com