<div><div>I've quoted some passages from the Servlet 3.0 spec to clarify.</div><div><br></div><div>As you know:</div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<br></blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
Prior to this release of the specification, listeners were invoked in a random order.</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
As of servlet 3.0, the order in which listeners are invoked is defined in “Assembling</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
the descriptor from web.xml, web-fragment.xml and annotations”</blockquote></div><div><br></div><div><div>The spec acknowledges that:</div></div><div><br></div><div><div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
Since the specification allows the application configuration resources to be</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
composed of multiple configuration files (web.xml and web-fragment.xml),</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
discovered and loaded from several different places in the application, the question</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
of ordering must be addressed.</blockquote><div><br></div><div>The web.xml (or web-fragment.xml) must have a <name> element to participate in ordering.</div><div><br></div><div>Since you are dealing with web.xml, you will need to use the absolute ordering:</div>
<div><br></div><div>1. Absolute ordering: an <absolute-ordering> element in the web.xml.</div><div> a. In this case, ordering preferences that would have been handled by case 2</div><div> below must be ignored.</div>
<div> b. The web.xml MUST be processed before any of the web-fragments listed in the</div><div> absolute-ordering element.</div><div> c. Any <name> element direct children of the <absolute-ordering> MUST be</div>
<div> interpreted as indicating the absolute ordering in which those named web-</div><div> fragments, which may or may not be present, must be processed.</div><div> d. The <absolute-ordering> element may contain zero or one <others /></div>
<div> element. The required action for this element is described below. If the</div><div> <absolute-ordering> element does not contain an <others/> element,</div><div> any web-fragment not specifically mentioned within <name /> elements</div>
<div> MUST be ignored. Excluded jars are not scanned for annotated servlets, filters</div><div> or listeners. However, if a servlet, filter or listener from an excluded jar is listed</div><div> in web.xml or a non-excluded web-fragment.xml, then it's annotations will</div>
<div> apply unless otherwise excluded by metadata-complete.</div><div> ServletContextListeners discovered in TLD files of excluded jars are not</div><div> able to configure filters and servlets using the programmatic APIs. Any</div>
<div> attempt to do so will result in an IllegalStateException. If a discovered</div><div> ServletContainerInitializer is loaded from an excluded jar, it will be</div><div> ignored. Excluded jars are not scanned for classes to be handled by any</div>
<div> ServletContainerInitializer.</div><div> e. Duplicate name exception: if, when traversing the children of <absolute-</div><div> ordering>, multiple children with the same <name> element are encountered,</div>
<div> only the first such occurrence must be considered.</div></div></div><div><br></div><div>Hopefully you can parse all that and get further along. I recommend you checkout the spec for more details, and let us know your results!</div>
<div><br></div><div>-Dan</div><div><br></div><div class="gmail_quote">On Wed, Mar 24, 2010 at 3:20 AM, Nicklas Karlsson <span dir="ltr"><<a href="mailto:nickarls@gmail.com">nickarls@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<div><br></div><div> I'm tinkering with the servlet listener -> CDI event bridge in the seam-servlet module and noticed that currently the WeldListener is placed last in the PostWebMetadataDeployer in weld-int.</div>
<div>I changed this (and verified it with the debugger) but still my own servlet listener fires first (expecting the contexts to be up), causing problems. Any theories as to why this is? How could we guarantee that</div>
<div>
the WeldListener is the first one to fire?<br clear="all"> <br>---<br>Nik<br>
</div>
<br>_______________________________________________<br>
weld-dev mailing list<br>
<a href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/weld-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/weld-dev</a><br></blockquote></div><br><br clear="all"><br>-- <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">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>