Apologies, I sent my last email in haste :). But the issues I face involved GeoServerDataDirectory holding onto state (appplicationContext,catalog,data directory root) from a previous setup. So this problem only occurs when when a non one time setup is run after a one time setup, and then another one time test is run... I think.
Anyways, the time killer was that te problems are hard to debug. For two reasons: 1) they dont occur in isolation. I cant run the single test that is failing, because it does not fail unless i run it with the rest of the tests 2) i get different results when i run in eclipse vs maven. Anyways, I think the one time setup stuff is great, just that it seems a bit easier to shoot yourself in the foot now than before where everything was recreated for each test. But I know hat was slow so its a tradeoff. And yes, I think the change you suggest is the way forward. Maybe instead of whining in emails i should just do it :). -Justin Andrea Aime wrote: > Justin Deoliveira ha scritto: >> Hi all, >> >> I just wasted four hours tracking down yet another problem which >> resulted from the one time testing setup running into an issue with the >> singleton we all love: GeoServerDataDirectory. The issue is once again >> that the singleton holds onto state which is not properly reinintalized >> when the mock test data setup is recreated. > > >> This is the third time where i have run into such an issue while working >> on the new config. Perhaps not any of you are running into these issues >> because are not developing on trunk, or only doing backports. But >> currently i am making some major changes and relying on these tests is >> starting to eat up a lot of time where i am not productive, and its not >> even really an issue with my code. > > A little confused here. How does "one time testing" enter the picture > here? The main idea behind it was to make running tests faster and > thus have more free development time, not the opposite :) > Under a "one time setup" testing the mock test data setup should > not be recreated, but reused over and over, if the data directory > is somehow changed by the test, then it's not read only configuration > wise and "one time" should not be used. > >> Phew... ok apologies for the rant. But I want to drive the point home >> that the way that singleton works is unreliable in a test environment, >> and its currently at the base of all "resource loading". And i bring >> this up because during the code sprint we are going to be making even >> bigger changes, and having to deal with issues like these is going to >> hurt us even more. > > I don't understand exactly what problem you faced (state persistence, > but how?), but it seems that turning DataDirectory into a bean declared > in the Spring context would solve the problem, right? > A quick look with Eclipse suggests GeoServerDataDirectory is used > in 113 distinct points in the code base. I did not check, but > hopefully all users are somehow declared in the Spring context or > can be feeded the dd reference by some collaborating object that is > declared there. > So it just seems a matter of making a big, but relatively mechanical, > change to the code base, and the code spring seems like an appropriate > place to do it. Say, half a day for two developers? > > Cheers > Andrea > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > !DSPAM:4007,4833c7de9641012714783! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
