Hi, On 05.10.2010 14:46, Bertrand Delacretaz wrote: > Hi, > > On Tue, Oct 5, 2010 at 2:39 PM, Felix Meschberger <[email protected]> wrote: > ... >>>> >>>> sling/trunk/launchpad/integration-tests/src/main/java/org/apache/sling/launchpad/webapp/integrationtest/servlets/post/PostServletVersionableTest.java >>>> ... >>>> @Override >>>> protected void setUp() throws Exception { >>>> + // enable autoCheckout for the tests >>>> ... >>>> + assertPostStatus(CFG_URL, 302, config, null); >>>> ... >>>> + Thread.sleep(500); // give async config update some time >>> >> ...We have to wait for the configuration to propagate to the Sling Post >> Servlet and for the Sling Post Servlet to restart. This is asynchronous. >> AFAICT there is no good (non-intrusive) way to find out whether the >> Sling Post Servlet has been updated with the correct configuration.... > > Checking for the service in the OSGi console might help? But I'm not > sure how to find out that the service has been restarted.
There's always the timeing incertainty involved with asynchronous calls. > >> >> As a workaround, we could update the configuration in the test methods >> depending on this configuration instead of doing it in the setUp method >> for all tests (even though setUp is definitely the right place for this)... > > I'm not following, not sure what differences this would make. Not all tests in the PostServletVersionableTest class really depend on the configuration. By moving the configuration setup to the respective methods we could reduce the time it takes to execute all tests of the class. > >> >> Or is there a way to push the configuration before any of the >> PostServletVersionableTest tests run and to remove the configuration >> again after the PostServletVersionableTest tests have run ?... > > We might need to create a utility that does that, and talks to the > OSGi console (or to a specific test helper service) to find out when > those config changes have actually been executed. I think more of a @BeforeClass/@AfterClass setup. This would still create configuration and add a delay, but only once instead of before each test method execution. > > In short: no worries if this is the only test where we need this, a > delay is probably good enough, but if we need more of this I'd rather > create a config manipulation utility. I don't worry about this delay ;-) Regards Felix > > -Bertrand >
