[weld-dev] Ordering of servlet listeners

[David Allen]

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