Re: [weld-dev] Ordering of servlet listeners

Nik, You might have to post in the JBoss AS development forum to find the answer. Maybe Ales would know too since he's done a lot of work with deployers. I have no idea how the ordering is being handled by the meta-data beans. - David Am Mittwoch, den 24.03.2010, 18:16 +0200 schrieb Nicklas Karlsson: > Yep but this is on implementation level, the JBoss - weld integration > sticks the WeldListener in all deployments through meta-data > manipulation. Previously it just got the list of listeners and added > it to the end of the list (i.e. not with a xml file). I tried putting > it first but that didn't help so the question is, "is the ordering > done at a later stage?" and "how can we get it first in all cases?" > and "can we simulate a web-fragment etc so that the ordering is > portable?" > > On Wed, Mar 24, 2010 at 5:33 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; > wrote: > I've quoted some passages from the Servlet 3.0 spec to > clarify. > > > As you know: > > Prior to this release of the specification, > listeners were invoked in a random order. > As of servlet 3.0, the order in which listeners > are invoked is defined in “Assembling > the descriptor from web.xml, web-fragment.xml > and annotations” > > > The spec acknowledges that: > > > Since the specification allows the > application configuration resources to be > composed of multiple configuration > files (web.xml and web-fragment.xml), > discovered and loaded from several > different places in the application, the question > of ordering must be addressed. > > > The web.xml (or web-fragment.xml) must have a <name> element > to participate in ordering. > > > Since you are dealing with web.xml, you will need to use the > absolute ordering: > > > 1. Absolute ordering: an <absolute-ordering> element in the > web.xml. > a. In this case, ordering preferences that would have been > handled by case 2 > below must be ignored. > b. The web.xml MUST be processed before any of the > web-fragments listed in the > absolute-ordering element. > c. Any <name> element direct children of the > <absolute-ordering> MUST be > interpreted as indicating the absolute ordering in which > those named web- > fragments, which may or may not be present, must be > processed. > d. The <absolute-ordering> element may contain zero or one > <others /> > element. The required action for this element is > described below. If the > <absolute-ordering> element does not contain an > <others/> element, > any web-fragment not specifically mentioned within > <name /> elements > MUST be ignored. Excluded jars are not scanned for > annotated servlets, filters > or listeners. However, if a servlet, filter or listener > from an excluded jar is listed > in web.xml or a non-excluded web-fragment.xml, then it's > annotations will > apply unless otherwise excluded by metadata-complete. > ServletContextListeners discovered in TLD files of > excluded jars are not > able to configure filters and servlets using the > programmatic APIs. Any > attempt to do so will result in an > IllegalStateException. If a discovered > ServletContainerInitializer is loaded from an excluded > jar, it will be > ignored. Excluded jars are not scanned for classes to be > handled by any > ServletContainerInitializer. > e. Duplicate name exception: if, when traversing the > children of <absolute- > ordering>, multiple children with the same <name> > element are encountered, > only the first such occurrence must be considered. > > > 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! > > > -Dan > > > > On Wed, Mar 24, 2010 at 3:20 AM, Nicklas Karlsson > <nickarls(a)gmail.com&gt; wrote: > > > Hi, > > > 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. > 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 > the WeldListener is the first one to fire? > > --- > Nik > > > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > > > -- > 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 > > > > > -- > --- > Nik > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev