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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,4833c7de9641012714783!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com