[weld-dev] Ordering of servlet listeners

[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 at 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
>> 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 at gmail.com>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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20100324/3abbd5d3/attachment-0001.html