I'm following the weld-dev, no worries. ;-)
(although, if I don't reply, then JBossAS dev forum is definitely the place to reach
I'll have a look on how this ordering is done.
Or Remy might already know this ootb. :-)
On Mar 24, 2010, at 9:50 AM, David Allen wrote:
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
I have no idea how the ordering is being handled by the meta-data beans.
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
> On Wed, Mar 24, 2010 at 5:33 PM, Dan Allen <dan.j.allen(a)gmail.com>
> I've quoted some passages from the Servlet 3.0 spec to
> 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
> 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
> 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
> 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!
> On Wed, Mar 24, 2010 at 3:20 AM, Nicklas Karlsson
> <nickarls(a)gmail.com> wrote:
> 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?
> weld-dev mailing list
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
> weld-dev mailing list
weld-dev mailing list