Hi all,
Dwins and I again today ran into the indeterministic test problem in which were both getting failures on trunk in different instances. And it was again indeed a result of initializing the crs subsystem.
The failures on my part were resulting only in eclipse. I am still unsure of the root cause but I found a fix by changing the following in GeoServerAbstractTestSupport:
if (Boolean.TRUE.equals(Hints.getSystemDefault(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER))) {
Hints.putSystemDefault(Hints.FORCE_AXIS_ORDER_HONORING, "http");
}
The change is to remove the guard around setting the FORCE_AXIS_ORDER_HONORING hint, and always setting it. The result is that all tests pass in eclipse.
So my questions are for Andrea (i think):
1. What is the rationale behind checking the default for the FORCE_LONGITUDE_... hint before setting the FORCE_AXIS_... hint.
2. What are the repercussions of always setting the FORCE_AXIS_... hint?
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Hi all,
Dwins and I again today ran into the indeterministic test problem in which were both getting failures on trunk in different instances. And it was again indeed a result of initializing the crs subsystem.
The failures on my part were resulting only in eclipse. I am still unsure of the root cause but I found a fix by changing the following in GeoServerAbstractTestSupport:
if (Boolean.TRUE.equals(Hints.getSystemDefault(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER))) {
Hints.putSystemDefault(Hints.FORCE_AXIS_ORDER_HONORING, "http");
}
The change is to remove the guard around setting the FORCE_AXIS_ORDER_HONORING hint, and always setting it. The result is that all tests pass in eclipse.
So my questions are for Andrea (i think):
1. What is the rationale behind checking the default for the FORCE_LONGITUDE_... hint before setting the FORCE_AXIS_... hint.
2. What are the repercussions of always setting the FORCE_AXIS_... hint?
The code is thought out so that if someone want GeoServer to operate
in EPSG native mode (lat before lon) he can. That requires the user to just set up a system variable stating that he does not want the
FORCE_LONGITUDE_FIRST_AXIS_ORDER to be honoured. In that case, also
the FORCE_AXIS_ORDER_HONORING should be avoided.
Since this feature is not exactly at the top of our users demands
(no one ever asked about it that I can remember),
we can just forget about it and force lon/lat order and friends
all the way.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi all,
Dwins and I again today ran into the indeterministic test problem in which were both getting failures on trunk in different instances. And it was again indeed a result of initializing the crs subsystem.
The failures on my part were resulting only in eclipse. I am still unsure of the root cause but I found a fix by changing the following in GeoServerAbstractTestSupport:
if (Boolean.TRUE.equals(Hints.getSystemDefault(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER))) {
Hints.putSystemDefault(Hints.FORCE_AXIS_ORDER_HONORING, "http");
}
The change is to remove the guard around setting the FORCE_AXIS_ORDER_HONORING hint, and always setting it. The result is that all tests pass in eclipse.
So my questions are for Andrea (i think):
1. What is the rationale behind checking the default for the FORCE_LONGITUDE_... hint before setting the FORCE_AXIS_... hint.
2. What are the repercussions of always setting the FORCE_AXIS_... hint?
The code is thought out so that if someone want GeoServer to operate
in EPSG native mode (lat before lon) he can. That requires the user to just set up a system variable stating that he does not want the
FORCE_LONGITUDE_FIRST_AXIS_ORDER to be honoured. In that case, also
the FORCE_AXIS_ORDER_HONORING should be avoided.
Since this feature is not exactly at the top of our users demands
(no one ever asked about it that I can remember),
we can just forget about it and force lon/lat order and friends
all the way.
Cheers
Andrea
It's probably worth noting that the check Justin refers to is in GeoServerAbstractTestSupport, so we can remove it without changing code that is shipped as part of a GeoServer release. Since we want the tests to be consistent, it's probably a good thing to remove conditionals from the setup code, right?
-d
David Winslow ha scritto:
It's probably worth noting that the check Justin refers to is in GeoServerAbstractTestSupport, so we can remove it without changing code that is shipped as part of a GeoServer release. Since we want the tests to be consistent, it's probably a good thing to remove conditionals from the setup code, right?
Ah, I thought you were talking about GeoServerInitStartupListener.
Yeah sure, the test code does not need the if.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Ah, I thought you were talking about GeoServerInitStartupListener.
Yeah sure, the test code does not need the if.
Yeah, I was def referring to the test cases. The issue only pops up in a repeated tear down / set up sequence. It would be nice to figure out what that sequence that is causing the problem is and why the hints are being reset.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Ah, I thought you were talking about GeoServerInitStartupListener.
Yeah sure, the test code does not need the if.
Yeah, I was def referring to the test cases. The issue only pops up in a repeated tear down / set up sequence. It would be nice to figure out what that sequence that is causing the problem is and why the hints are being reset.
Yeah, I wish I understood how hints and the factory subsystem work
in tandem, but I guess if anybody asked me to read a text in ancient
Aramaic(1) I would have better luck 
Cheers
Andrea
[1] http://en.wikipedia.org/wiki/Aramaic
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.