[Geoserver-users] Malformed XML in WMS getCapabilities response [Sec=Unclassified]

GeoServer GeoServer User
1

Hi all,

I am getting malformed xml returned from a WMS getCapabilities request in geoserver 1.6.0. It looks like it is missing two closing tags right before the closing tag, and has used an empty tag there instead.

I’ve put a copy of the getCapabilities document at http://data.aad.gov.au/temp/miles/getCapabilities.xml
Also a copy of the log file at http://data.aad.gov.au/temp/miles/geoserver.log - all I did was fire up the instance and issue a getcapabilities request.

There are a couple of exceptions thrown when the getCapabilities request is issued -
org.geotools.referencing.wkt.UnformattableObjectException: This “AxisDirection” object is too complex for WKT syntax.
at org.geotools.referencing.wkt.Formattable.toWKT(Formattable.java:185)

Followed by a NullPointerException -
at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleFeatureType(WMSCapsTransformer.java:814)

I am using SRS 3031 - I think this is the problem because I cannot replicate the problem on a fresh geoserver instance.

Though I don’t think the WKT is the problem, SRS 3031 is defined as:

PROJCS["WGS 84 / Antarctic Polar Stereographic", 
  GEOGCS["WGS 84", 
    DATUM["World Geodetic System 1984", 
      SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]], 
      AUTHORITY["EPSG","6326"]], 
    PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], 
    UNIT["degree", 0.017453292519943295], 
    AXIS["Geodetic longitude", EAST], 
    AXIS["Geodetic latitude", NORTH], 
    AUTHORITY["EPSG","4326"]], 
  PROJECTION["Polar Stereographic (variant B)", AUTHORITY["EPSG","9829"]], 
  PARAMETER["central_meridian", 0.0], 
  PARAMETER["standard_parallel_1", -71.0], 
  PARAMETER["false_easting", 0.0], 
  PARAMETER["false_northing", 0.0], 
  UNIT["m", 1.0], 
  AXIS["Easting", "North along 90 deg East"], 
  AXIS["Northing", "North along 0 deg"], 
  AUTHORITY["EPSG","3031"]]

Does anyone know how I can fix the problem?

Many Thanks,

Miles Jordan

Applications Developer
The Australian Antarctic Division

Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not the
intended recipient, you are notified that use or dissemination of this communication is
strictly prohibited by Commonwealth law. If you have received this transmission in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/

2

Hi Miles,

The malformed xml is a result of the fact that geoserver dying in the middle of trying to get some srs information about the feature type and not really handling it elegantly.

The root cause seems to be an issue in the referencing module. I can replicate it easily by simply setting any layer to have an SRS of 3031 and then issuing a wms capabilities request.

Andrea: does this make sense to you? Or is this something that we need to take to geotools-devel and ask martin about?

Miles Jordan wrote:

Hi all,
I am getting malformed xml returned from a WMS getCapabilities request in geoserver 1.6.0. It looks like it is missing two closing </Layer> tags right before the closing </Capability> tag, and has used an empty <Style/> tag there instead.
I've put a copy of the getCapabilities document at http://data.aad.gov.au/temp/miles/getCapabilities.xml
Also a copy of the log file at http://data.aad.gov.au/temp/miles/geoserver.log - all I did was fire up the instance and issue a getcapabilities request.
There are a couple of exceptions thrown when the getCapabilities request is issued -
org.geotools.referencing.wkt.UnformattableObjectException: This "AxisDirection" object is too complex for WKT syntax.
at org.geotools.referencing.wkt.Formattable.toWKT(Formattable.java:185)
Followed by a NullPointerException -
at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleFeatureType(WMSCapsTransformer.java:814)
I am using SRS 3031 - I think this is the problem because I cannot replicate the problem on a fresh geoserver instance.
Though I don't think the WKT is the problem, SRS 3031 is defined as:

PROJCS["WGS 84 / Antarctic Polar Stereographic", GEOGCS["WGS 84", DATUM["World Geodetic System 1984", SPHEROID["WGS 84", 6378137.0, 298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943295], AXIS["Geodetic longitude", EAST], AXIS["Geodetic latitude", NORTH], AUTHORITY["EPSG","4326"]], PROJECTION["Polar Stereographic (variant B)", AUTHORITY["EPSG","9829"]], PARAMETER["central_meridian", 0.0], PARAMETER["standard_parallel_1", -71.0], PARAMETER["false_easting", 0.0], PARAMETER["false_northing", 0.0], UNIT["m", 1.0], AXIS["Easting", "North along 90 deg East"], AXIS["Northing", "North along 0 deg"], AUTHORITY["EPSG","3031"]]

Does anyone know how I can fix the problem?
Many Thanks,
Miles Jordan

Applications Developer
The Australian Antarctic Division

___________________________________________________________________________

    Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not the
intended recipient, you are notified that use or dissemination of this communication is
strictly prohibited by Commonwealth law. If you have received this transmission in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and
DELETE the message.
        Visit our web site at http://www.antarctica.gov.au/
___________________________________________________________________________

!DSPAM:4007,47c4cd79202761015089218!

------------------------------------------------------------------------

-------------------------------------------------------------------------
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/

!DSPAM:4007,47c4cd79202761015089218!

------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,47c4cd79202761015089218!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

3

Miles Jordan ha scritto:

Hi all,
I am getting malformed xml returned from a WMS getCapabilities request in geoserver 1.6.0. It looks like it is missing two closing </Layer> tags right before the closing </Capability> tag, and has used an empty <Style/> tag there instead.
I've put a copy of the getCapabilities document at http://data.aad.gov.au/temp/miles/getCapabilities.xml
Also a copy of the log file at http://data.aad.gov.au/temp/miles/geoserver.log - all I did was fire up the instance and issue a getcapabilities request.
There are a couple of exceptions thrown when the getCapabilities request is issued -
org.geotools.referencing.wkt.UnformattableObjectException: This "AxisDirection" object is too complex for WKT syntax.
at org.geotools.referencing.wkt.Formattable.toWKT(Formattable.java:185)

This error is thrown because GeoServer is trying to encode 3031 in WKT
with the strict encoding code path, that does actually throw an exception if th SRS definition cannot fully conveyed into a WKT form.
The srsList uses a lenient path that accepts degradation, that's
why you see the WKT encoding there... but it's not a 100% equivalent
of what you can find in the official EPSG database.

Anyways, this is not the cause of the problem in the capabilities
document generation, if the wkt encoding fails the exception is
catched, logged, and the generation continues.
I agree it's annoying to see the exception thought, and it may
be misleading, so I'll modify the code to use the lenient path
for WKT encoding.

Followed by a NullPointerException -
at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleFeatureType(WMSCapsTransformer.java:814)

This one is the real cause of failure, and it relates to alternate
styles usage in the feature type configuration page (you know, the list
of styles where you can choose a second, third and so on style for a layer, to be published in the capabilities as an alterantive).
I'm not sure how it is triggered thought. Maybe you had set an
alternate style in that layer and then that style got deleted?

Cheers
Andrea

4

Andrea Aime ha scritto:

Followed by a NullPointerException -
at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleFeatureType(WMSCapsTransformer.java:814)

This one is the real cause of failure, and it relates to alternate
styles usage in the feature type configuration page (you know, the list
of styles where you can choose a second, third and so on style for a layer, to be published in the capabilities as an alterantive).
I'm not sure how it is triggered thought. Maybe you had set an
alternate style in that layer and then that style got deleted?

Just confirmed this is a way to trigger the NPE. Associate a style
as a secondary one on the feature type configuration form, then
delete that style, and you'll get exactly that stack trace.
Going to add some checks preventing deletion of used styles:
http://jira.codehaus.org/browse/GEOS-1770

Cheers
Andrea