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> 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
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
Since you are dealing with web.xml, you will need to use the absolute
1. Absolute ordering: an <absolute-ordering> element in the web.xml.
a. In this case, ordering preferences that would have been handled by
below must be ignored.
b. The web.xml MUST be processed before any of the web-fragments listed
c. Any <name> element direct children of the <absolute-ordering> MUST be
interpreted as indicating the absolute ordering in which those named
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
<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
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
apply unless otherwise excluded by metadata-complete.
ServletContextListeners discovered in TLD files of excluded jars are
able to configure filters and servlets using the programmatic APIs.
attempt to do so will result in an IllegalStateException. If a
ServletContainerInitializer is loaded from an excluded jar, it will
ignored. Excluded jars are not scanned for classes to be handled by
e. Duplicate name exception: if, when traversing the children of
ordering>, multiple children with the same <name> element are
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
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597