[Geoserver-users] strange fail in Getcapabilities (1.7.1 version)

pere_roca · January 9, 2009, 1:02pm

hi,
I have just updated from 1.5 (I think) to 1.7.1 and everything seems to work
fine but I'm getting strange error with GetCapabilities.

The resulting XML capabilities
(http://edit.csic.es/geoserver/wms?request=GetCapabilities) doesn't work, as
it's not well-formed: an extra </Layer> is added at the end of the document
(you can see it in the resulting alert that appears when using IE on
http://edit.csic.es/edit_geo/prototype/edit.html or using Firebug and
Firefox 3).

As it did not happened before I have to suspect about Geoserver; any idea?
the logs just say... WARN [responses.helpers] -
java.lang.NullPointerException

thanks,
Pere Roca
--
View this message in context: http://www.nabble.com/strange-fail-in-Getcapabilities-(1.7.1-version)-tp21371878p21371878.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Andrea_Aime3 · January 9, 2009, 1:31pm

pere roca ha scritto:

hi,
I have just updated from 1.5 (I think) to 1.7.1 and everything seems to work
fine but I'm getting strange error with GetCapabilities.

The resulting XML capabilities
(http://edit.csic.es/geoserver/wms?request=GetCapabilities) doesn't work, as
it's not well-formed: an extra </Layer> is added at the end of the document
(you can see it in the resulting alert that appears when using IE on
http://edit.csic.es/edit_geo/prototype/edit.html or using Firebug and
Firefox 3).

As it did not happened before I have to suspect about Geoserver; any idea? the logs just say... WARN [responses.helpers] -
java.lang.NullPointerException

Ouch, that does not give us much to work with... you sure there is nothing else in $GEOSERVER_DATA_DIR/logs/geoserver.log?
All the logging statements I've found in the code seem to dump
a fuller stack trace. I need it in order to diagnose the exact
issue.

Anyways, if I had to guess, I'd say a layer group is probably
mis-configured

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

pere_roca · January 12, 2009, 9:25am

dear Andreas,

thanks again for your help.
I have tried Geoserver_developer_logging, and for GetCapabilities requests just a java.lang.NullPointerException, but when I reload Geoserver…

…
2009-01-12 10:14:46,251 DEBUG [org.vfny.geoserver.requests] - First 4 bytes of XML doc are : 3C (‘<’) 3F (‘?’) 63 (‘c’) 6F (‘o’)
2009-01-12 10:14:46,251 DEBUG [org.vfny.geoserver.requests] - Charset detection phase 1. Inferred encoding: UTF-8
2009-01-12 10:14:46,251 DEBUG [org.vfny.geoserver.requests] - Invalid(?) XML declaration: <?conf.
2009-01-12 10:14:46,251 DEBUG [org.vfny.geoserver.requests] - Charset detection phase 2. Charset in XML declaration is null.

[THIS IS BECAUSE THE CATALOG.XML starts with <?config.xml version="1.0" encoding="UTF-8"?> but I have checked the backup of my previous Geoserver and it started like this and worked fine…also tried to use <?xml instead of config.xml but complains also about it]

Also for each feature type says…

2009-01-09 14:51:07,630 INFO [geoserver.catalog] - Loaded feature type ‘topp:coast_earth’
2009-01-09 14:51:07,630 DEBUG [geoserver.requests] - First 4 bytes of XML doc are : 3C (‘<’) 66 (‘f’) 65 (‘e’) 61 (‘a’)
2009-01-09 14:51:07,630 DEBUG [geoserver.requests] - Charset detection phase 1. Inferred encoding: UTF-8
2009-01-09 14:51:07,630 DEBUG [geoserver.requests] - Invalid(?) XML declaration: <featu.
2009-01-09 14:51:07,630 DEBUG [geoserver.requests] - Charset detection phase 2. Charset in XML declaration is null.

Now is complaining because each info.xml starts with <featureType datastore =
GetMap requests are working fine, just GetCapabilities fails;
What I’m missing? thanks in advance,

Pere

2009/1/9 Andrea Aime <aaime@anonymised.com>

pere roca ha scritto:

hi,
I have just updated from 1.5 (I think) to 1.7.1 and everything seems to work
fine but I’m getting strange error with GetCapabilities.
The resulting XML capabilities
(http://edit.csic.es/geoserver/wms?request=GetCapabilities) doesn’t work, as
it’s not well-formed: an extra is added at the end of the document
(you can see it in the resulting alert that appears when using IE on
http://edit.csic.es/edit_geo/prototype/edit.html or using Firebug and
Firefox 3).

As it did not happened before I have to suspect about Geoserver; any idea? the logs just say… WARN [responses.helpers] -
java.lang.NullPointerException

Ouch, that does not give us much to work with… you sure there is nothing else in $GEOSERVER_DATA_DIR/logs/geoserver.log?
All the logging statements I’ve found in the code seem to dump
a fuller stack trace. I need it in order to diagnose the exact
issue.

Anyways, if I had to guess, I’d say a layer group is probably
mis-configured

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Pere Roca Ristol
Biòleg i especialista GIS
Museo Nacional de Ciencias Naturales (CSIC)
Visita l’EDIT mapViewer!
http://edit.csic.es/edit_geo/prototype/edit.html

Andrea_Aime3 · January 12, 2009, 9:36am

pere roca ristol ha scritto:

dear Andreas,

thanks again for your help.
I have tried Geoserver_developer_logging, and for GetCapabilities requests just a java.lang.NullPointerException, but when I reload Geoserver...

......
2009-01-12 10:14:46,251 DEBUG [org.vfny.geoserver.requests] - First 4 bytes of XML doc are : 3C ('<') 3F ('?') 63 ('c') 6F ('o')
2009-01-12 10:14:46,251 DEBUG [org.vfny.geoserver.requests] - Charset detection phase 1. Inferred encoding: UTF-8
2009-01-12 10:14:46,251 DEBUG [org.vfny.geoserver.requests] - Invalid(?) XML declaration: <?conf.
2009-01-12 10:14:46,251 DEBUG [org.vfny.geoserver.requests] - Charset detection phase 2. Charset in XML declaration is `null`.

[THIS IS BECAUSE THE CATALOG.XML starts with <?config.xml version="1.0" encoding="UTF-8"?> but I have checked the backup of my previous Geoserver and it started like this and worked fine...also tried to use <?xml instead of config.xml but complains also about it]

Also for each feature type says...

2009-01-09 14:51:07,630 INFO [geoserver.catalog] - Loaded feature type 'topp:coast_earth'
2009-01-09 14:51:07,630 DEBUG [geoserver.requests] - First 4 bytes of XML doc are : 3C ('<') 66 ('f') 65 ('e') 61 ('a')
2009-01-09 14:51:07,630 DEBUG [geoserver.requests] - Charset detection phase 1. Inferred encoding: UTF-8
2009-01-09 14:51:07,630 DEBUG [geoserver.requests] - Invalid(?) XML declaration: <featu.
2009-01-09 14:51:07,630 DEBUG [geoserver.requests] - Charset detection phase 2. Charset in XML declaration is `null`.

Now is complaining because each info.xml starts with <featureType datastore =
GetMap requests are working fine, just GetCapabilities fails;
What I'm missing? thanks in advance,

What we're missing is a log statement that dumps the full exception
instead of eating it, so the problem is first and foremost in sloppy
coding on our part.

Unfortunately I have no idea where the error is occurring.
Anyways, have a look at what the incomplete capabilities document
contains. What is the last layer it reports, is it a vector layer,
a coverage one, or a group one? The code builds the caps following
that order.

In order to easily diagnose it I would need a full dump of your
data dir along with all your data, external databases and so on...
a nightmare...

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime3 · January 12, 2009, 9:58am

pere roca ha scritto:

hi,
I have just updated from 1.5 (I think) to 1.7.1 and everything seems to work
fine but I'm getting strange error with GetCapabilities.

The resulting XML capabilities
(http://edit.csic.es/geoserver/wms?request=GetCapabilities) doesn't work, as
it's not well-formed: an extra </Layer> is added at the end of the document
(you can see it in the resulting alert that appears when using IE on
http://edit.csic.es/edit_geo/prototype/edit.html or using Firebug and
Firefox 3).

Looked at the xml document returned with the validating xml editor
embedded in Eclipse. The issue happens mid document, with the layer
topp:utm_incertidum, whose Style is not encoded, the <Style>
element is opened but never closed. It seems the style that
layer refers to cannot be found?

I managed to reproduce the same output as you by forcefully
deleting a .sld file from the data directory, yet, that
produced a proper exception in the logs, both at load
time and when writing out the capabilities, here is
a sample:

12 gen 10:49:49 WARN [responses.helpers] -
java.lang.NullPointerException
  at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleFeatureType(WMSCapsTransformer.java:732)
  at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleFeaturesTree(WMSCapsTransformer.java:645)
  at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleLayers(WMSCapsTransformer.java:517)
  at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleCapability(WMSCapsTransformer.java:334)
  at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.encode(WMSCapsTransformer.java:218)
  at org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse(TransformerBase.java:714)
  at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
  at org.geotools.xml.transform.TransformerBase$Task.run(TransformerBase.java:296)
  at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.java:129)
  at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.java:108)
  at org.vfny.geoserver.wms.responses.WMSCapabilitiesResponse.execute(WMSCapabilitiesResponse.java:148)
  at org.geoserver.ows.adapters.ResponseAdapter.getMimeType(ResponseAdapter.java:48)
  at org.geoserver.ows.Dispatcher.response(Dispatcher.java:689)
  at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:215)
  at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
  at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
  at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
  at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
  at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
  at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
  at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
  at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
  at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
  at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
  at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
  at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
  at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
  at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
  at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
  at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
  at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
  at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
  at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
  at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
  at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:163)
  at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
  at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
  at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
  at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
  at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
  at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
  at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
  at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
  at org.mortbay.jetty.Server.handle(Server.java:324)
  at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
  at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828)
  at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
  at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
  at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
  at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
  at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)

It's quite strange you don't have such a thing in yours.

Anyways, the proper GeoServer behaviour in such case should be to
dump an error message when loading the layer, and then disable it
so that it's not served anymore.
Opening a jira issue about that:
http://jira.codehaus.org/browse/GEOS-2558

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

pere_roca · January 12, 2009, 12:54pm

dear Andrea,

althought the Style for utm_incertidum exists (so I think you can remove the message from JIRA), I have removed this FeatureType from catalog.

When reloading…(extended debug version ;.)) still the same problems as before.
I wonder why doesn’t understand the XML declaration of catalog.xml and each info.xml?? this Xml declarations is correct, right? <?config.xml version="1.0" encoding="UTF-8"?>

2009-01-12 12:24:17,884 DEBUG [org.vfny.geoserver.global] - File is valid: /Data_Directory/plugIns
2009-01-12 12:24:17,885 TRACE [org.vfny.geoserver.global] - loading configuration file java.io.FileReader@anonymised.com
2009-01-12 12:24:17,887 TRACE [org.vfny.geoserver.global] - getting element text for [name: null]
2009-01-12 12:24:17,887 TRACE [org.vfny.geoserver.global] - getting element text for [description: null]
2009-01-12 12:24:17,887 TRACE [org.vfny.geoserver.global] - getting element text for [class: null]
…
DEBUG [org.vfny.geoserver.global] - File is valid: /Data_Directory/validation
2009-01-12 12:24:18,007 INFO [org.geoserver.catalog] - Disposing datastore ‘edit_postGIS’
2009-01-12 12:24:18,007 DEBUG [org.vfny.geoserver.requests] - First 4 bytes of XML doc are : 3C (‘<’) 3F (‘?’) 63 (‘c’) 6F (‘o’)
2009-01-12 12:24:18,008 DEBUG [org.vfny.geoserver.requests] - Charset detection phase 1. Inferred encoding: UTF-8
2009-01-12 12:24:18,008 DEBUG [org.vfny.geoserver.requests] - Invalid(?) XML declaration: <?conf.
2009-01-12 12:24:18,008 DEBUG [org.vfny.geoserver.requests] - Charset detection phase 2. Charset in XML declaration is null.
2009-01-12 12:24:18,011 DEBUG [org.geoserver] - Found Java environment variable : ‘RELINQUISH_LOG4J_CONTROL’ to be unset
2009-01-12 12:24:18,011 DEBUG [org.geoserver] - Found Servlet context parameter : ‘RELINQUISH_LOG4J_CONTROL’ to be unset
2009-01-12 12:24:18,011 DEBUG [org.geoserver] - Found System environment variable : ‘RELINQUISH_LOG4J_CONTROL’ to be unset
…
2009-01-12 12:24:18,019 DEBUG [org.geoserver.logging] - Logging output to file ‘/logs/geoserver.log’
2009-01-12 12:24:18,019 DEBUG [org.geoserver.logging] - FINISHED CONFIGURING GEOSERVER LOGGING -------------------------

AGAIN, WHEN LOADING CATALOG.XML runs the error…

2009-01-12 12:24:18,019 DEBUG [org.vfny.geoserver.requests] - First 4 bytes of XML doc are : 3C (‘<’) 3F (‘?’) 63 (‘c’) 6F (‘o’)
2009-01-12 12:24:18,019 DEBUG [org.vfny.geoserver.requests] - Charset detection phase 1. Inferred encoding: UTF-8
2009-01-12 12:24:18,019 DEBUG [org.vfny.geoserver.requests] - Invalid(?) XML declaration: <?conf.
2009-01-12 12:24:18,019 DEBUG [org.vfny.geoserver.requests] - Charset detection phase 2. Charset in XML declaration is null.
…
2009-01-12 12:24:18,059 INFO [org.geoserver.catalog] - Processed data store ‘edit_postGIS’, enabled
2009-01-12 12:24:18,060 DEBUG [org.vfny.geoserver.global] - in string url
…
2009-01-12 12:24:18,102 INFO [org.geoserver.catalog] - Processed coverage store ‘sfDem’, enabled
…
AGAIN, FOR EACH FEATURE TYPE runs the error:
2009-01-12 12:24:18,102 DEBUG [org.vfny.geoserver.requests] - First 4 bytes of XML doc are : 3C (‘<’) 66 (‘f’) 65 (‘e’) 61 (‘a’)
2009-01-12 12:24:18,102 DEBUG [org.vfny.geoserver.requests] - Charset detection phase 1. Inferred encoding: UTF-8
2009-01-12 12:24:18,102 DEBUG [org.vfny.geoserver.requests] - Invalid(?) XML declaration: <featu.
2009-01-12 12:24:18,102 DEBUG [org.vfny.geoserver.requests] - Charset detection phase 2. Charset in XML declaration is null.
2009-01-12 12:24:18,126 INFO [org.geoserver.catalog] - Loaded feature type ‘topp:country_earth’
…
2009-01-12 12:24:27,768 INFO [org.geoserver.confg] - Loading service ‘wms’

2009-01-12 12:24:27,771 DEBUG [org.vfny.geoserver.global] - setting styles to:

… SETTING UP STYLES WITHOUT ERROR

2009-01-12 12:24:27,906 DEBUG [org.vfny.geoserver.action] - request: /admin/loadFromXML.do
2009-01-12 12:24:27,907 DEBUG [org.vfny.geoserver.action] - forward: null

I tried GetCapabilities with geoserver_developer logging and maybe it would be helpful if we Geoserver would log which LegendURL is failing… but a GetLegendGraphic error would make a GetCapabilities request fail? sounds strange.

2009-01-12 13:48:51,377 DEBUG [org.vfny.geoserver.wms.responses.helpers] - producing a capabilities document for GetCapabilities [service: WMS, version: 1.1.1]
2009-01-12 13:48:51,404 DEBUG [org.vfny.geoserver.wms.responses.helpers] - Collecting summarized latlonbbox and common SRS…
2009-01-12 13:48:51,404 DEBUG [org.vfny.geoserver.wms.responses.helpers] - Summarized LatLonBBox is Env[-180.16666666666666 : 1092.0, -90.0 : 180.0]
2009-01-12 13:40:24,058 DEBUG [org.vfny.geoserver.wms.responses.helpers] - Adding GetLegendGraphic call as LegendURL
2009-01-12 13:40:24,059 WARN [org.vfny.geoserver.wms.responses.helpers] -
java.lang.NullPointerException
2009-01-12 13:40:24,059 DEBUG [org.vfny.geoserver.wms.responses.helpers] - Adding GetLegendGraphic call as LegendURL
…

thanks a lot for your help.

Pere

2009/1/12 Andrea Aime <aaime@anonymised.com>

pere roca ha scritto:

hi,
I have just updated from 1.5 (I think) to 1.7.1 and everything seems to work
fine but I’m getting strange error with GetCapabilities.
The resulting XML capabilities
(http://edit.csic.es/geoserver/wms?request=GetCapabilities) doesn’t work, as
it’s not well-formed: an extra is added at the end of the document
(you can see it in the resulting alert that appears when using IE on
http://edit.csic.es/edit_geo/prototype/edit.html or using Firebug and
Firefox 3).

Looked at the xml document returned with the validating xml editor
embedded in Eclipse. The issue happens mid document, with the layer
topp:utm_incertidum, whose Style is not encoded, the
element is opened but never closed. It seems the style that
layer refers to cannot be found?

I managed to reproduce the same output as you by forcefully
deleting a .sld file from the data directory, yet, that
produced a proper exception in the logs, both at load
time and when writing out the capabilities, here is
a sample:

12 gen 10:49:49 WARN [responses.helpers] -
java.lang.NullPointerException
at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleFeatureType(WMSCapsTransformer.java:732)
at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleFeaturesTree(WMSCapsTransformer.java:645)
at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleLayers(WMSCapsTransformer.java:517)
at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.handleCapability(WMSCapsTransformer.java:334)
at org.vfny.geoserver.wms.responses.helpers.WMSCapsTransformer$CapabilitiesTranslator.encode(WMSCapsTransformer.java:218)
at org.geotools.xml.transform.TransformerBase$XMLReaderSupport.parse(TransformerBase.java:714)
at org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
at org.geotools.xml.transform.TransformerBase$Task.run(TransformerBase.java:296)
at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.java:129)
at org.geotools.xml.transform.TransformerBase.transform(TransformerBase.java:108)
at org.vfny.geoserver.wms.responses.WMSCapabilitiesResponse.execute(WMSCapabilitiesResponse.java:148)
at org.geoserver.ows.adapters.ResponseAdapter.getMimeType(ResponseAdapter.java:48)
at org.geoserver.ows.Dispatcher.response(Dispatcher.java:689)
at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:215)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:73)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.geoserver.filters.ReverseProxyFilter.doFilter(ReverseProxyFilter.java:163)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:41)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)

It’s quite strange you don’t have such a thing in yours.

Anyways, the proper GeoServer behaviour in such case should be to
dump an error message when loading the layer, and then disable it
so that it’s not served anymore.
Opening a jira issue about that:
http://jira.codehaus.org/browse/GEOS-2558

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Pere Roca Ristol
Biòleg i especialista GIS
Museo Nacional de Ciencias Naturales (CSIC)
Visita l’EDIT mapViewer!
http://edit.csic.es/edit_geo/prototype/edit.html

Andrea_Aime3 · January 12, 2009, 1:52pm

pere roca ristol ha scritto:

dear Andrea,

althought the Style for utm_incertidum exists (so I think you can remove the message from JIRA),

Nope, the message will stay there as I reproduced the bug myself
on my configuration, so even if it does not match your use case,
it's still a bug.

I have removed this FeatureType from catalog.

Hum... I just got the capabilities from your server (http://edit.csic.es/geoserver/wms?request=GetCapabilities) and
unless there is some caching going on, the feature type
is still there, as well as the error I've seen in the xml
returned (its style element is opened, but not closed).

I also just got the caps from another program (curl, on the command
line) where there cannot be any client side caching, and it's
still there, here is a sample of what I'm getting:

...
       <Layer queryable="1">
         <Name>topp:utm_incertidum</Name>
         <Title>Uncertainity, Scarabaeidae, Iberian Peninsula, UTM 2500 sqkm</Title>
         <Abstract>Uncertainity, Scarabaeidae, Iberian Peninsula, UTM 2500 sqkm</Abstract>
         <KeywordList>
           <Keyword>completeness</Keyword>
           <Keyword>edit_postGIS_spatial</Keyword>
         </KeywordList>
         <SRS>EPSG:4326</SRS>
         
         <LatLonBoundingBox minx="-9.6215705871582" miny="35.6565170288086" maxx="4.86428022384644" maxy="43.8030624389648"/>
         <BoundingBox SRS="EPSG:4326" minx="-9.6215705871582" miny="35.6565170288086" maxx="4.86428022384644" maxy="43.8030624389648"/>
         <Style>
           <Layer queryable="1">
             <Name>topp:point_pol</Name>
             <Title>point_pol_Type</Title>
             <Abstract>Generated from edit3_postGIS</Abstract>
             <KeywordList>
               <Keyword>edit3_postGIS</Keyword>
               <Keyword>point_pol</Keyword>
             </KeywordList>
             <SRS>EPSG:4326</SRS>
...

So it's either happening some caching on your side, or the
feature type is still there.
It even shows in the map preview here:

http://edit.csic.es/geoserver/mapPreview.do

and if I follow the OpenLayers link:

http://edit.csic.es/geoserver/wms?bbox=-10.345863127708432,35.249189758300794,5.588572764396672,44.21038970947261&styles=&Format=application/openlayers&request=GetMap&version=1.1.1&layers=topp:utm_incertidum&width=800&height=422&srs=EPSG:4326

I get the following error message as the body of the service
exception:

Could not find a style for layer topp:utm_incertidum, either none was specified or no default style is available for it

When reloading...(extended debug version ;.)) still the same problems as before.
I wonder why doesn't understand the XML declaration of catalog.xml and each info.xml?? this Xml declarations is correct, right? <?config.xml version="1.0" encoding="UTF-8"?>

This is overzealus logging and it's not really reporting a problem
in the configuration, it's a problem in the code instead (it should
not log that crap).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

pere_roca · January 12, 2009, 4:47pm

dear Andrea,

yes, it’s true, utm_incertidum existed when you tested, and now is definetly removed together with other missconfigured files so it works now ;.) thanks a lot for your time and sorry.

I was completely obsessed with the end of Getcapabilities.xml:

There is a that envolves all the other Layers! it’s a little confusing and I thought the error was here.

just another question: in the that “covers” all the other Layer, maxx of LatLonBoundingBox is " maxx=“1092.0”

This value is calculated by Geoserver; why should it fail?

EPSG:23030
EPSG:3034
EPSG:4326

best regards,
Pere

2009/1/12 Andrea Aime <aaime@anonymised.com>

pere roca ristol ha scritto:

dear Andrea,

althought the Style for utm_incertidum exists (so I think you can remove the message from JIRA),

Nope, the message will stay there as I reproduced the bug myself
on my configuration, so even if it does not match your use case,
it’s still a bug.

I have removed this FeatureType from catalog.

Hum… I just got the capabilities from your server (http://edit.csic.es/geoserver/wms?request=GetCapabilities) and
unless there is some caching going on, the feature type
is still there, as well as the error I’ve seen in the xml
returned (its style element is opened, but not closed).

I also just got the caps from another program (curl, on the command
line) where there cannot be any client side caching, and it’s
still there, here is a sample of what I’m getting:

…

topp:utm_incertidum
Uncertainity, Scarabaeidae, Iberian Peninsula, UTM 2500 sqkm Uncertainity, Scarabaeidae, Iberian Peninsula, UTM 2500 sqkm completeness edit_postGIS_spatial EPSG:4326 topp:point_pol point_pol_Type Generated from edit3_postGIS edit3_postGIS point_pol EPSG:4326 ...
So it’s either happening some caching on your side, or the
feature type is still there.
It even shows in the map preview here:

http://edit.csic.es/geoserver/mapPreview.do

and if I follow the OpenLayers link:

http://edit.csic.es/geoserver/wms?bbox=-10.345863127708432,35.249189758300794,5.588572764396672,44.21038970947261&styles=&Format=application/openlayers&request=GetMap&version=1.1.1&layers=topp:utm_incertidum&width=800&height=422&srs=EPSG:4326

I get the following error message as the body of the service
exception:

Could not find a style for layer topp:utm_incertidum, either none was specified or no default style is available for it

When reloading…(extended debug version ;.)) still the same problems as before.
I wonder why doesn’t understand the XML declaration of catalog.xml and each info.xml?? this Xml declarations is correct, right? <?config.xml version="1.0" encoding="UTF-8"?>

This is overzealus logging and it’s not really reporting a problem
in the configuration, it’s a problem in the code instead (it should
not log that crap).

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Pere Roca Ristol
Biòleg i especialista GIS
Museo Nacional de Ciencias Naturales (CSIC)
Visita l’EDIT mapViewer!
http://edit.csic.es/edit_geo/prototype/edit.html