Prior to this release of the specification, listeners were invoked in a random order.

in “Assembling

configuration resources to be

web-fragment.xml),

application, the question

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

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 12:16 PM, Nicklas Karlsson <nickarls(a)gmail.com&gt; wrote: 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?" Frankly, I don't understand why JBoss is not using the web-fragment.xml (or emulating it) so that it plays by the Servlet 3.0 rules.

-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 _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

On 24 Mar 2010, at 16:17, Dan Allen wrote: > On Wed, Mar 24, 2010 at 12:16 PM, Nicklas Karlsson <nickarls(a)gmail.com&gt; wrote: > 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?" > > Frankly, I don't understand why JBoss is not using the web-fragment.xml (or emulating it) so that it plays by the Servlet 3.0 rules. You mean to add the WeldListener? Because the Weld support in JBoss AS predates Servlet 3.0 support .... It should be trivial to switch to using a web.xml fragment, using the same system we have to insert faces-config.xml into the deployment, if this will actually help with Nik's problem?

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

> I'm following the weld-dev, no worries. ;-) > (although, if I don't reply, then JBossAS dev forum is definitely the place to reach me) > > I'll have a look on how this ordering is done. > Or Remy might already know this ootb. :-) Ok, so there are already some default listeners that go first (the shared ones from the default web.xml). Do you really need to be before these ones ? It's quite simple really, the order is the order of declaration in the descriptors, so the first one in web.xml goes first (after the ones in the shared web.xml). Did I get the question right ?

On Wed, 2010-03-24 at 11:41 -0700, Ales Justin wrote: > Yes. :-) > > I guess the order from web.xml is then the same as in ServletMetaData (or whatever data we use to hold the listeners metadata)? > --> since we don't use web.xml, but add Weld listener programmatically in a deployer Well, yes and no. The list of listeners that JBossWebMetaData has is ordered (and you can replace it, of course :) ), but there's another JBossWebMetaData for the shared web.xml that goes before it. In the shared stuff, there's: - a security listener which does stuff (ask Anil) - two JSF listeners > Is there a way to know which listeners come from default web.xml? Hum, no :( Now that you mention it, maybe I could do that "shared stuff" handling in its own deployer, taking the "final" JBossWebMetaData and merging it with the shared JBossWebMetaData to get a "final final" JBossWebMetaData. > So we can place our Weld listener just after those. Hopefully. -- Remy Maucherat <rmaucher(a)redhat.com&gt; Red Hat Inc

On Wed, 2010-03-24 at 11:00 -0700, Ales Justin wrote: > I'm following the weld-dev, no worries. ;-) > (although, if I don't reply, then JBossAS dev forum is definitely the place to reach me) > > I'll have a look on how this ordering is done. > Or Remy might already know this ootb. :-) Ok, so there are already some default listeners that go first (the shared ones from the default web.xml). Do you really need to be before these ones ? It's quite simple really, the order is the order of declaration in the descriptors, so the first one in web.xml goes first (after the ones in the shared web.xml).