Hmmm... It seems my change was not as good as I thought... :-(

Strangely I had tested it by running the samples/servlet with Resin 3.x
and it worked fine. However I've just also run it on several other
containers and it appears it fails on Orion 2.x for example.

The reason is simple. There are now new redirectors (named
DefaultServletRedirector, etc). However, the samples servlet was merging
some web.xml to define init-parameters. These init-parameters are
defined on the ServletRedirector name. However, for tests that do not
specify which redirector to use (i.e. 99% of them), the <cactus> task
uses the first redirector it finds (i.e the DefaultServletRedirector
one). Thus tests who checks for init-parameters fail...

Note: How could the tests work fine on Resin 3.x... This is a mystery to
me.

There are several other complications. It's not as easy as I thought. I
am thus reverting my changes.

Note for Gertjan: The fact that you need to add the default redirector
before the secured redirector is/was already documented on the
cactifywar page:

"
In the next example, we add a security-constrained instance of the
servlet redirector to be able to run tests using authentication (see
Using Authentication for details). Note that you need to provide an
empty servlet redirector element, so that the default redirector is
included along side the secured redirector (it would just be overridden
otherwise). 

<cactifywar srcfile="${build.dir}/my.war"
destfile="${build.dir}/test.war">
  <servletredirector/>
  <servletredirector name="ServletRedirectorSecure"
      mapping="/ServletRedirectorSecure" roles="test"/>
</cactifywar> 
"

Thanks
-Vincent

> -----Original Message-----
> From: Vincent Massol [mailto:[EMAIL PROTECTED]
> Sent: 02 April 2004 13:54
> To: 'Cactus Developers List'
> Subject: RE: Modifying the behavior of <cactifywar> WRT redirectors
> 
> Done (see cvs diff email).
> 
> I have named the default redirectors DefaultServletRedirector,
> DefaultJspRedirector and DefaultFilterRedirector.
> 
> Thanks
> -Vincent
> 
> > -----Original Message-----
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]
> > Sent: 02 April 2004 11:36
> > To: 'Cactus Developers List'
> > Subject: Modifying the behavior of <cactifywar> WRT redirectors
> >
> > Hi,
> >
> > The current algorithm for the <cactifywar> task is to add the
default
> > redirectors only if the user has not specified any redirector of the
> > same type (servlet, jsp, filter).
> >
> > However this is causing a problem.
> >
> > The algorithm in the <cactus> task is to use the first redirector
> found
> > in web.xml and use it to verify if the container is up and running.
If
> > the user has defined a secured redirector, it fails of course...
> >
> > I'm proposing that we *always* add the non-secured default
redirectors
> > first in the web.xml and then the additional ones defined by the
user.
> >
> > That assumes that the default redirector names are now reserved and
> > cannot be used by end users (currently ServletRedirector,
> JspRedirector
> > and FilterRedirector).
> >
> > We could also change these default names to be:
> > DefaultNotSecuredServletRedirector, etc
> >
> > I think it would be better as it would not impact any existing
Cactus
> > users. Whereas keeping the ServletRedirector names could possibly
> impact
> > those who are using these names in their <cacitywar> task to define
> > secure redirectors for example.
> >
> > What do you think? Ok to go ahead?
> >
> > Thanks
> >
> > -Vincent
> > Wanna see JUnit in Action?
> > (http://manning.com/massol)
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to