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
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
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
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
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
element. The required action for this element is
described below. If the
<absolute-ordering> element does not contain an
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
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
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
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
weld-dev mailing list