commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: [chain] When does a filter run?
Date Fri, 06 May 2005 18:13:01 GMT
On 5/6/05, Samad Haytham <samad.haytham@gmail.com> wrote:
> Question about how filters work as we are seeing behaviour that is a
> little different from what we expected.  We setup a filter as the
> second command in a 4 command chain.  Following is an example config
> file.
> 
> <chain name="myChain">
>   <command id="1"....
>    />
>   <command id="myfilter"..... />
>   <command id="3".../>
>   <command id="4" ...../>
> </chain>
> 
> If command 1 throws an Exception, myfilter's postprocess is never
> called.  Looking at the code, we realized that the filters are
> executed in reverse order from where an exception is thrown (or the
> chain ends).  Meaning that the filter's postprocess method is only
> called if the execute method is called.  What we wanted was a way to
> have one filter's postprocess method handle any exceptions that are
> thrown.  To enable that with how Chains currently works, we move our
> filter to the beginning of the chain.  Are there any other ways to do
> this?  Define a Filter (no matter where in the Chain - in our case it
> was the last command called JobEnd) and guarantee that its postprocess
> is called?

Filters are working as you describe (postprocess is only called if
execute is called), and that is as they are designed.  A typical use
case is that you want to allocate a resource (say, a JDBC connection)
that is needed by commands that will be executed later in the chain,
so you do this in the execute() method of a filter and then release it
in the postprocess() method.

If a command in the chain *prior* to this filter threw an exception,
you'd have never allocated the connection in the first place, so there
would be no reason to release it.

If you want a generalized exception catcher, either:

* Put this filter at the beginning of your chain

* Or, implement a customized version of Chain that traps any exception
  thrown while it is executing and passes it to some method for handling.

Craig


> 
> BTW, its been nice working with chains.  Any information as to what we
> can expect in the next release?
> 
> Thanks
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message