[weld-dev] Ordering of servlet listeners
Ales Justin
ales.justin at gmail.com
Wed Mar 24 14:00:42 EDT 2010
I'm following the weld-dev, no worries. ;-)
(although, if I don't reply, then JBossAS dev forum is definitely the place to reach me)
I'll have a look on how this ordering is done.
Or Remy might already know this ootb. :-)
-Ales
On Mar 24, 2010, at 9:50 AM, David Allen wrote:
> 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
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
More information about the weld-dev
mailing list