You seem to know that you are doing so I'll leave the ball with you ;-)

The situation we're aming for is that when people throw in web.xml:s and web-fragment.xmls and @WebListener:s, the order (of course) follows that of the Servlet specification but we have sneaked in the WeldListener before that. Now how to guarantee portability, that this has also been done when throwing the same application in another appserver is another thing...

On Wed, Mar 24, 2010 at 9:04 PM, Remy Maucherat <rmaucher@redhat.com> wrote:
On Wed, 2010-03-24 at 11:41 -0700, Ales Justin wrote:
> Yes. :-)
>
> I guess the order from web.xml is then the same as in ServletMetaData (or whatever data we use to hold the listeners metadata)?
> --> since we don't use web.xml, but add Weld listener programmatically in a deployer

Well, yes and no. The list of listeners that JBossWebMetaData has is
ordered (and you can replace it, of course :) ), but there's another
JBossWebMetaData for the shared web.xml that goes before it.

In the shared stuff, there's:
- a security listener which does stuff (ask Anil)
- two JSF listeners

> Is there a way to know which listeners come from default web.xml?

Hum, no :( Now that you mention it, maybe I could do that "shared stuff"
handling in its own deployer, taking the "final" JBossWebMetaData and
merging it with the shared JBossWebMetaData to get a "final final"
JBossWebMetaData.

> So we can place our Weld listener just after those.

Hopefully.

--
Remy Maucherat <rmaucher@redhat.com>
Red Hat Inc




--
---
Nik