jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@pivolis.com>
Subject RE: ServletTestRunner and multiple Web Applications
Date Sun, 27 Jun 2004 11:11:15 GMT
Hi Volker,

Ok I understand now and yes your use case is valid :-)

The problem lies in our ConfigurationInitializer class which is called from
a lot of different places. For example it's called in static blocks in
ServletTestCase, FitlerTestCase and JspTestCase classes, i.e. in each of
your Cactus test cases. The reason is that there's no hook in JUnit for
executing things once at the level of a TestCase (you have to use a Suite
for that and so far we have not forced Cactus users to use a Cactus suite to
wrap all of their test cases...). Thus the hook we created was a static

Thus to prevent multiple initializations we set a static isInitialized flag
and do not reinitialize the config:

    public static synchronized void initialize()
        if (!isInitialized)
            isInitialized = true;

This is what is causing you the trouble.

I guess one easy thing we could do is to reinitialize the config in the
init() method of the ServletTestRunner. That will solve it for the
ServletTestRunner because it is running in the *same* JVM as the Cactus
server-side code...

However, that will not fix it for the other front ends where it's more
tricky. We'll need to tackle it on a case by case basis...

Ok, I've committed the fix for the ServletTestRunner. I haven't written any
automated test case for it though... :-( (it's quite hard to do...) 

Could you let me know if it works? (I've uploaded a nightly build in


> -----Original Message-----
> From: Volker Krebs [mailto:volker.krebs@abas.de]
> Sent: lundi 21 juin 2004 08:33
> To: Cactus Users List
> Subject: Re: ServletTestRunner and multiple Web Applications
> Hello,
> Vincent Massol wrote:
> > Hi Volker,
> >
> > Your use case (using the same cactus installation to test different web
> > applications) is not supported by Cactus. I'm actually surprised it
> > could work at all! :-)
> >
> > The way to run Cactus tests on a given web application is by cactifying
> > this web application. So if you have 2 web applications, you're supposed
> > to cactify 2 web applications, each installing its own cactus
> > redirectors.
> >
> > This means that it was pure luck that Cactus was working for you
> > before... ;-)
> >
> > That said, I'm curious to understand better your use case as I'm always
> > happy to improve Cactus. I have a few questions:
> >
> > - where are the cactus tests located? In test1 webapp? In test2 webapp?
> > In another webapp?
> > - in which webapp are the cactus redirectors installed?
> >
> I'm not quite sure if my use case is wrong for cactus. What I am doing
> is deploying und undeploying cactified webapplications each with its own
> cactus.jar, ServletRedirector and tests. The Tomcat gets not restarted
> between the test applications.
> > Also, the call to setSystemProperties() happen in the doGet() method,
> > i.e. for each call to the Servlet Test Runner. Thus, if the contextURL
> > property changes, it should work fine, no? It means that you would need
> > to change this property between your 2 webapp tests, which seems normal
> > to me. What am I missing?
> >
> Like Kazuhito wrote, the lifetime of the system property is the point,
> it does not get deleted after an redeployment of an webapplication. So
> the new System.setProperties is never called, because we still got that
> property from the previous application.
> But you are wright, when I manualy set the property in each application
> everything works fine. But I can only do this by calling
> System.setProperties("cactus.contextURL"...) in each test application.
> If I try to use the cactus.properties it gets ignored (I think that is
> what Kazuhito also meant).
> Maybe one easy way to get rid of the system property is to delete it
> when ServletTestRunner gets undeployed. Than anything should work like
> before.
> thanks,
> Volker
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-user-help@jakarta.apache.org
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.711 / Virus Database: 467 - Release Date: 25/06/2004

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.711 / Virus Database: 467 - Release Date: 25/06/2004

View raw message