Hi all,
Dwins and I have been trying to nail down why tests are failing on the build server and not on our local machines. Actually its worse than that:
* build server via hudson -> FAIL
* build server from command line -> PASS
* local machine via eclispse -> FAIL
* local machine from command line -> PASS
The error in eclipse i get is the same as via hudson so I did some debugging. Basically what this boils down to is re-projection that is occurring between long-lat and lat-long when it should not be. Trying to figure out why I got lost and am left with a number of questions for Andrea since he is really the only one who understands how it all works :).
So... Andrea:
On GeoServer startup we set a few hints which tell the CRS subsystem "stuff". Basically my understanding is we tell it 2 things:
1. We set the XY "hint"
2. We then force certain factories (http) to honor the hint
So... my question is what should be the result after this happens? My understanding is:
CRS.decode( "EPSG:4326" ) -> XY
CRS.decode( "http://…/epsg.xml#4326" ) -> XY
CRS.decode( "urn:...." ) -> YX
Is this correct?
My second question is how this relates to testing. Now this is just a guess but my impression of why we get such different results in different running configurations is because tests are running in different order. And on top of that we are throwing one-time setup testing into the mix. I wonder if there is just some cleanup that is not happening... like resetting of those global hints or something. Just a guess... i am kind of reaching at this point.
It might be nice to be able to turn off one-time testing by flipping a switch. Just to rule out such situations where errors are occurring due to the sharing of test context. Especially since these failures do not apply to an actual instance of GeoServer. Any chance this is easily possible?
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Hi Justin,
for the time being I've made the new tests to extend from GeoServerAbstractTestSupport as a workaround. It should work, but now hudson is complaining there's a conflict when it svn updated the wms pom.xml.
I guess that's because you changed it manually while figuring out what happens under different build environments. If so please revert the pom so hudson can run the build.
cheers,
Gabriel
Justin Deoliveira escribió:
Hi all,
Dwins and I have been trying to nail down why tests are failing on the build server and not on our local machines. Actually its worse than that:
* build server via hudson -> FAIL
* build server from command line -> PASS
* local machine via eclispse -> FAIL
* local machine from command line -> PASS
The error in eclipse i get is the same as via hudson so I did some debugging. Basically what this boils down to is re-projection that is occurring between long-lat and lat-long when it should not be. Trying to figure out why I got lost and am left with a number of questions for Andrea since he is really the only one who understands how it all works :).
So... Andrea:
On GeoServer startup we set a few hints which tell the CRS subsystem "stuff". Basically my understanding is we tell it 2 things:
1. We set the XY "hint"
2. We then force certain factories (http) to honor the hint
So... my question is what should be the result after this happens? My understanding is:
CRS.decode( "EPSG:4326" ) -> XY
CRS.decode( "http://…/epsg.xml#4326" ) -> XY
CRS.decode( "urn:...." ) -> YX
Is this correct?
My second question is how this relates to testing. Now this is just a guess but my impression of why we get such different results in different running configurations is because tests are running in different order. And on top of that we are throwing one-time setup testing into the mix. I wonder if there is just some cleanup that is not happening... like resetting of those global hints or something. Just a guess... i am kind of reaching at this point.
It might be nice to be able to turn off one-time testing by flipping a switch. Just to rule out such situations where errors are occurring due to the sharing of test context. Especially since these failures do not apply to an actual instance of GeoServer. Any chance this is easily possible?
Ahh... I did not notice that they were not ... so that makes sense then why the CRS subsystem was mis behaving.
And yes, I manually modified the pom on the server to figure out why the tests were failing. Changed back and happy to report the build is happy again.
-Justin
Gabriel Roldan wrote:
Hi Justin,
for the time being I've made the new tests to extend from GeoServerAbstractTestSupport as a workaround. It should work, but now hudson is complaining there's a conflict when it svn updated the wms pom.xml.
I guess that's because you changed it manually while figuring out what happens under different build environments. If so please revert the pom so hudson can run the build.
cheers,
Gabriel
Justin Deoliveira escribió:
Hi all,
Dwins and I have been trying to nail down why tests are failing on the build server and not on our local machines. Actually its worse than that:
* build server via hudson -> FAIL
* build server from command line -> PASS
* local machine via eclispse -> FAIL
* local machine from command line -> PASS
The error in eclipse i get is the same as via hudson so I did some debugging. Basically what this boils down to is re-projection that is occurring between long-lat and lat-long when it should not be. Trying to figure out why I got lost and am left with a number of questions for Andrea since he is really the only one who understands how it all works :).
So... Andrea:
On GeoServer startup we set a few hints which tell the CRS subsystem "stuff". Basically my understanding is we tell it 2 things:
1. We set the XY "hint"
2. We then force certain factories (http) to honor the hint
So... my question is what should be the result after this happens? My understanding is:
CRS.decode( "EPSG:4326" ) -> XY
CRS.decode( "http://…/epsg.xml#4326" ) -> XY
CRS.decode( "urn:...." ) -> YX
Is this correct?
My second question is how this relates to testing. Now this is just a guess but my impression of why we get such different results in different running configurations is because tests are running in different order. And on top of that we are throwing one-time setup testing into the mix. I wonder if there is just some cleanup that is not happening... like resetting of those global hints or something. Just a guess... i am kind of reaching at this point.
It might be nice to be able to turn off one-time testing by flipping a switch. Just to rule out such situations where errors are occurring due to the sharing of test context. Especially since these failures do not apply to an actual instance of GeoServer. Any chance this is easily possible?
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.