Hi Justin,
I was trying to add a test for http://jira.codehaus.org/browse/GEOS-1528
fix. Now, I'm hitting a couple of limitations I'd like to discuss.
The first one is validation related... if I do a
getAsDom("wms?request=GetCapabilities")
in a test (as a smoke test) to check a valid XML document
is returned, I will get an error because the parser is trying
to access the dtd. I understand GeoServer is not really running
during the test so the dtd located in geoserver/schemas/wms/... is
not accessible, but I was wondering if there is any workaround
(besing doing a getAsString()).
The second one is that to test the fix I need to register a
feature type in the mock data with a specific SRS, a custom
one in fact, to make sure it does not have the bursa wolf
parameters defined. But I see no way to control the mock
data this much. Depending on the test I guess one might
want to specify the various parameters used in MockData.info(name),
that is, at least the srs, the bbox, the srs handling.
Ideas? Should I go and extend MockData accordingly?
Cheers
Andrea
Andrea Aime wrote:
Hi Justin,
I was trying to add a test for http://jira.codehaus.org/browse/GEOS-1528
fix. Now, I'm hitting a couple of limitations I'd like to discuss.
The first one is validation related... if I do a
getAsDom("wms?request=GetCapabilities")
in a test (as a smoke test) to check a valid XML document
is returned, I will get an error because the parser is trying
to access the dtd. I understand GeoServer is not really running
during the test so the dtd located in geoserver/schemas/wms/... is
not accessible, but I was wondering if there is any workaround
(besing doing a getAsString()).
Hmmm... I will look into this one. I am sure there is a workaround.
Maybe including the schemas in the mock data direcetory and pointing the
validator at it.
The second one is that to test the fix I need to register a
feature type in the mock data with a specific SRS, a custom
one in fact, to make sure it does not have the bursa wolf
parameters defined. But I see no way to control the mock
data this much. Depending on the test I guess one might
want to specify the various parameters used in MockData.info(name),
that is, at least the srs, the bbox, the srs handling.
Ideas? Should I go and extend MockData accordingly?
Well you can add a feature type dynamically from a test with
addFeautreType. And you can specify the srs of a geometry inside of the
properties file you specify. However it looks like info() ignores this
and just sets to 4326.
Perhaps addFeatureType should take a map which specifies all the
parameters that are stored in the info file. What do you think?
-Justin
Cheers
Andrea
!DSPAM:4007,4744559d72822143011171!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Andrea Aime wrote:
Hi Justin,
I was trying to add a test for http://jira.codehaus.org/browse/GEOS-1528
fix. Now, I'm hitting a couple of limitations I'd like to discuss.
The first one is validation related... if I do a
getAsDom("wms?request=GetCapabilities")
in a test (as a smoke test) to check a valid XML document
is returned, I will get an error because the parser is trying
to access the dtd. I understand GeoServer is not really running
during the test so the dtd located in geoserver/schemas/wms/... is
not accessible, but I was wondering if there is any workaround
(besing doing a getAsString()).
Hmmm... I will look into this one. I am sure there is a workaround.
Maybe including the schemas in the mock data direcetory and pointing the
validator at it.
The test I tried was looking for the dtd (not a schema in this case, thought I guess it does not make much of a difference) on localhost:8080/geoserver/schemas/wms/1.1.1/...
The second one is that to test the fix I need to register a
feature type in the mock data with a specific SRS, a custom
one in fact, to make sure it does not have the bursa wolf
parameters defined. But I see no way to control the mock
data this much. Depending on the test I guess one might
want to specify the various parameters used in MockData.info(name),
that is, at least the srs, the bbox, the srs handling.
Ideas? Should I go and extend MockData accordingly?
Well you can add a feature type dynamically from a test with
addFeautreType. And you can specify the srs of a geometry inside of the
properties file you specify. However it looks like info() ignores this
and just sets to 4326.
Perhaps addFeatureType should take a map which specifies all the
parameters that are stored in the info file. What do you think?
Looks good... a map with default values just like in the data
store factories? Or maybe just a plain map with well known keys.
Cheers
Andrea
The test I tried was looking for the dtd (not a schema in this case,
thought I guess it does not make much of a difference) on
localhost:8080/geoserver/schemas/wms/1.1.1/...
Yeah, i dont think it will matter much.
Looks good... a map with default values just like in the data
store factories? Or maybe just a plain map with well known keys.
I am thinking just a map with well known keys. The MockData method will
then use the map as an "override" for parameters in info.xml, if a key
does not exist in the map, it uses its default
Do you want to take a crack at this, or shall I? I would be happy to
since there are a few other testing related things i want to clean up.
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
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,47445a3690102143011171!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
The test I tried was looking for the dtd (not a schema in this case, thought I guess it does not make much of a difference) on localhost:8080/geoserver/schemas/wms/1.1.1/...
Yeah, i dont think it will matter much.
Looks good... a map with default values just like in the data
store factories? Or maybe just a plain map with well known keys.
I am thinking just a map with well known keys. The MockData method will
then use the map as an "override" for parameters in info.xml, if a key
does not exist in the map, it uses its default
Do you want to take a crack at this, or shall I? I would be happy to
since there are a few other testing related things i want to clean up.
If you want to, you have my blessing 
I should be working on wcs 1.1 these days 
Cheers
Andrea