TC4 B3: Filters and Load Order bug?

[Philippe Khalife <pk...@dinmar.com>]

This is a question about Servlet Specification Vs Implementation details.

The filters mappings are applied as per specifications, and in order.

However when initialized by the Container they start by Alphabetical order.
No matter what order I list these filter declarations in, "AuthFilter"
always gets started before "Initalizer", I could rename these but I think it
would be better to have filters initialized in the same order they are
listed, is this a feature that can make it in the next beta? or am  I
missing something?

    <filter>
         <filter-name>Initializer</filter-name>
         <filter-class>core.filter.Initializer</filter-class>
         <init-param>
	 	<param-name>LOG4J_CONFIG_FILE</param-name>
	 	<param-value>/core/config/log4j.properties</param-value>
	 </init-param>
         <init-param>
	 	<param-name>OACONFIG_CONFIG_FILE</param-name>
	 	<param-value>/core/config/oaconfig.properties</param-value>
	 </init-param>
         <init-param>
	 	<param-name>DB_CONFIG_FILE</param-name>
	 	<param-value>/core/config/db.properties</param-value>
	 </init-param>
         <init-param>
	 	<param-name>VELOCITY_CONFIG_FILE</param-name>
	 	<param-value>/core/config/velocity.properties</param-value>
	 </init-param>
    </filter>

    <filter>
        <filter-name>AuthFilter</filter-name>
        <filter-class>cd.filter.AuthFilter</filter-class>
	<init-param>
		<param-name>LOGIN_SCREEN</param-name>
		<param-value>/servlet/core.oas_Login</param-value>
	</init-param>
    </filter>

    <filter>
        <filter-name>AuthFilterStub</filter-name>
        <filter-class>cd.filter.AuthFilterStub</filter-class>
	<init-param>
		<param-name>LOGIN</param-name>
		<param-value>XXXX</param-value>
	</init-param>
	<init-param>
		<param-name>PASSWORD</param-name>
		<param-value>XXXXX</param-value>
	</init-param>
    </filter>




    <filter-mapping>
           <filter-name>Initializer</filter-name>
           <url-pattern>/*</url-pattern>
    </filter-mapping>

    <!-- This is Filter will insert Valid login and password Information
into the session  use it during testing -->
    <filter-mapping>
        <filter-name>AuthFilterStub</filter-name>
	<url-pattern>/servlet/*</url-pattern>
    </filter-mapping>

<!-- Disable this filter during testing, the AuthFilterStub will insert all
User information
    <filter-mapping>
        <filter-name>AuthFilter</filter-name>
	<url-pattern>/servlet/*</url-pattern>
    </filter-mapping>
-->

Re: TC4 B3: Filters and Load Order bug?

["Craig R. McClanahan" <cr...@apache.org>]

On Wed, 2 May 2001, Philippe Khalife wrote:

> 
> This is a question about Servlet Specification Vs Implementation details.
> 

Yah, there is always an interesting space between those two ... :-)

> The filters mappings are applied as per specifications, and in order.
> 
> However when initialized by the Container they start by Alphabetical order.
> No matter what order I list these filter declarations in, "AuthFilter"
> always gets started before "Initalizer", I could rename these but I think it
> would be better to have filters initialized in the same order they are
> listed, is this a feature that can make it in the next beta? or am  I
> missing something?
> 

Actually, you were just lucky, or unlucky as the case may be.

The set of filter definitions (i.e. one per <filter> element) is stored in
a HashMap while the web.xml file is being processed.  When it's time to
start them up, Tomcat iterates over the keys of this HashMap -- which
means that the ordering is essentially random.

What's also important to note is that the spec doesn't have *anything* to
say about initialization order.  It doesn't even promise to initialize
Filters when the web app starts -- that was an implementation choice I
made, because I felt people would want to know about problems sooner
rather than later.  The only guarantee is that a particular filter
instance will have been initialized before it is used to process a
request.

If you have order-sensitive operations to do at web app startup time, I
would suggest that you consider using an application event listener for
this purpose.  There, the ordering is guaranteed, along with the fact that
the listeners will be initialized prior to processing *any* request.

It should be fairly easy to split the initialization logic out of your
filters, and place it inside the contextStarted() event handler of one or
more listeners.  The objects you initialize can be exposed to your filters
either by storing them as servlet context attributes or sharing them as
static variables.  (Listeners and filters are loaded via the web app class
loader, so that "static" variables are global to the web app the way you
want them to be.)

Craig McClanahan