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