[Geoserver-devel] Production logging and WARN level events

Hi List,
I’m wondering if it’s possible to get GeoServer to log less to its log, at least when the user has set it to “production_logging” as I have. The problem is that every time I restart GeoServer (daily) I get a wall of WARN level events.

This is a problem from a sys-admins perspective because it makes it harder to create a simple script which looks for activity in the logs and sends an alert.

The following are the entries that I don’t believe I (as a user/admin) can do anything about:

2013-12-17 06:05:01,509 WARN [support.DisposableBeanAdapter] - Invocation of destroy method failed on bean with name ‘geoServerLoader’: org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean with name ‘GWCLifeCycleHandler’: Singleton bean creation not allowed while the singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)
2013-12-17 06:05:02,336 WARN [referencing.factory] - Axis elements found in a wkt definition, the force longitude first axis order hint might not be respected:
PROJCS[“WGS84 / Simple Mercator”, GEOGCS[“WGS 84”, DATUM[“WGS_1984”, SPHEROID[“WGS_1984”, 6378137.0, 298.257223563]], PRIMEM[“Greenwich”, 0.0], UNIT[“degree”, 0.017453292519943295]], PROJECTION[“Mercator_1SP_Google”], PARAMETER[“latitude_of_origin”, 0.0], PARAMETER[“central_meridian”, 0.0], PARAMETER[“scale_factor”, 1.0], PARAMETER[“false_easting”, 0.0], PARAMETER[“false_northing”, 0.0], UNIT[“m”, 1.0], AXIS[“x”, EAST], AXIS[“y”, NORTH], AUTHORITY[“EPSG”,“54004”]]
2013-12-17 06:05:10,479 WARN [geoserver.logging] - Suppressing StdOut logging. If you want to see GeoServer logs, be sure to look in ‘C:\Tomcat_Compass\bin..\instances\instance1\logs\GeoServer.log’
2013-12-17 06:05:11,883 WARN [config.CustomEditorConfigurer] - Passing PropertyEditor instances into CustomEditorConfigurer is deprecated: use PropertyEditorRegistrars or PropertyEditor class names instead. Offending key [org.geotools.util.Version; offending editor instance: org.geoserver.platform.util.VersionPropertyEditor@anonymised.com
2013-12-17 06:05:13,677 WARN [referencing.factory] - Axis elements found in a wkt definition, the force longitude first axis order hint might not be respected:
PROJCS[“WGS84 / Simple Mercator”, GEOGCS[“WGS 84”, DATUM[“WGS_1984”, SPHEROID[“WGS_1984”, 6378137.0, 298.257223563]], PRIMEM[“Greenwich”, 0.0], UNIT[“degree”, 0.017453292519943295]], PROJECTION[“Mercator_1SP_Google”], PARAMETER[“latitude_of_origin”, 0.0], PARAMETER[“central_meridian”, 0.0], PARAMETER[“scale_factor”, 1.0], PARAMETER[“false_easting”, 0.0], PARAMETER[“false_northing”, 0.0], UNIT[“m”, 1.0], AXIS[“x”, EAST], AXIS[“y”, NORTH], AUTHORITY[“EPSG”,“54004”]]

(I’m not even using that projection!)

Following that, there’s then these lines which aren’t clear as to what they mean:

2013-12-17 06:05:15,128 WARN [org.geoserver] - Ignoring store directory ‘layergroups’
2013-12-17 06:05:15,331 WARN [org.geoserver] - Ignoring store directory ‘styles’
2013-12-17 06:05:15,331 WARN [org.geoserver] - Ignoring store directory ‘Oracle Live - OSMM’
2013-12-17 06:05:15,331 WARN [org.geoserver] - Ignoring store directory ‘layergroups’
2013-12-17 06:05:18,170 WARN [org.geoserver] - Ignoring store directory ‘styles’

I don’t think any of the above sets of logging should be in Production logs at all.

And then there’s a list of every single layer telling me that I don’t have a primary key set in my Oracle (I know):

2013-12-17 06:05:30,899 WARN [geotools.jdbc] - Failure occurred while looking up the primary key with finder: org.geotools.jdbc.HeuristicPrimaryKeyFinder@anonymised.com
2013-12-17 06:05:30,899 WARN [geotools.jdbc] - No primary key or unique index found for OS_MM_CARTOGRAPHIC_SYMBOL.
2013-12-17 06:05:31,040 WARN [geotools.jdbc] - Unrecognized geometry type DEFAULT falling back on generic ‘GEOMETRY’

Ideally that wouldn’t be in there either, but can understand the case for why it could be.

Rather than just unilaterally opening a JIRA, I thought I’d ask the devs - should any of these really be in production logs? Or is this something that could be cleaned up so GeoServer starts clean?

Cheers,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

I am sure this list can be toned down, and I like the goal of making “GeoServer start clean”.

Lets have a look…

2013-12-17 06:05:01,509 WARN [support.DisposableBeanAdapter] - Invocation of destroy method failed on bean with name ‘geoServerLoader’: org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean with name ‘GWCLifeCycleHandler’: Singleton bean creation not allowed while the singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)

This looks to be a mistake that can be cleaned up.

2013-12-17 06:05:02,336 WARN [referencing.factory] - Axis elements found in a wkt definition, the force longitude first axis order hint might not be respected:

PROJCS[“WGS84 / Simple Mercator”, GEOGCS[“WGS 84”, DATUM[“WGS_1984”, SPHEROID[“WGS_1984”, 6378137.0, 298.257223563]], PRIMEM[“Greenwich”, 0.0], UNIT[“degree”, 0.017453292519943295]], PROJECTION[“Mercator_1SP_Google”], PARAMETER[“latitude_of_origin”, 0.0], PARAMETER[“central_meridian”, 0.0], PARAMETER[“scale_factor”, 1.0], PARAMETER[“false_easting”, 0.0], PARAMETER[“false_northing”, 0.0], UNIT[“m”, 1.0], AXIS[“x”, EAST], AXIS[“y”, NORTH], AUTHORITY[“EPSG”,“54004”]]

There are two reasons why WKT would be used:
a) one of your layers uses an “prj” file - in which case this warning is fair
b) geoserver, or your installation, includes additional custom definitions in an epsg.properties files - in which case this warning is far. However for the “built-in” additional codes we can probably suppress these warnings while parsing the file.

2013-12-17 06:05:10,479 WARN [geoserver.logging] - Suppressing StdOut logging. If you want to see GeoServer logs, be sure to look in ‘C:\Tomcat_Compass\bin..\instances\instance1\logs\GeoServer.log’

I expect this could be set to INFO.

2013-12-17 06:05:11,883 WARN [config.CustomEditorConfigurer] - Passing PropertyEditor instances into CustomEditorConfigurer is deprecated: use PropertyEditorRegistrars or PropertyEditor class names instead. Offending key [org.geotools.util.Version; offending editor instance: org.geoserver.platform.util.VersionPropertyEditor@anonymised.com

Looks to be something to fix.

2013-12-17 06:05:13,677 WARN [referencing.factory] - Axis elements found in a wkt definition, the force longitude first axis order hint might not be respected:

PROJCS[“WGS84 / Simple Mercator”, GEOGCS[“WGS 84”, DATUM[“WGS_1984”, SPHEROID[“WGS_1984”, 6378137.0, 298.257223563]], PRIMEM[“Greenwich”, 0.0], UNIT[“degree”, 0.017453292519943295]], PROJECTION[“Mercator_1SP_Google”], PARAMETER[“latitude_of_origin”, 0.0], PARAMETER[“central_meridian”, 0.0], PARAMETER[“scale_factor”, 1.0], PARAMETER[“false_easting”, 0.0], PARAMETER[“false_northing”, 0.0], UNIT[“m”, 1.0], AXIS[“x”, EAST], AXIS[“y”, NORTH], AUTHORITY[“EPSG”,“54004”]]

(I’m not even using that projection!)

Same deal as above, you can remove it from your data directory epsg.properties file if you are not using it.

2013-12-17 06:05:15,128 WARN [org.geoserver] - Ignoring store directory ‘layergroups’

2013-12-17 06:05:15,331 WARN [org.geoserver] - Ignoring store directory ‘styles’

Not sure either, something to fix in code or configuration?

2013-12-17 06:05:15,331 WARN [org.geoserver] - Ignoring store directory ‘Oracle Live - OSMM’
2013-12-17 06:05:15,331 WARN [org.geoserver] - Ignoring store directory ‘layergroups’
2013-12-17 06:05:18,170 WARN [org.geoserver] - Ignoring store directory ‘styles’

I don’t think any of the above sets of logging should be in Production logs at all.

I think we should clean up our example configuration so they do not occur, so if these warnings are useful in a production setting they will be respected.

And then there’s a list of every single layer telling me that I don’t have a primary key set in my Oracle (I know):

2013-12-17 06:05:30,899 WARN [geotools.jdbc] - Failure occurred while looking up the primary key with finder: org.geotools.jdbc.HeuristicPrimaryKeyFinder@anonymised.com
2013-12-17 06:05:30,899 WARN [geotools.jdbc] - No primary key or unique index found for OS_MM_CARTOGRAPHIC_SYMBOL.
2013-12-17 06:05:31,040 WARN [geotools.jdbc] - Unrecognized geometry type DEFAULT falling back on generic ‘GEOMETRY’

Ideally that wouldn’t be in there either, but can understand the case for why it could be.

Think we could make an extra connection parameter here, the default setting can produce the warnings, and provide an explicit setting to handle the “I know” case.

Rather than just unilaterally opening a JIRA, I thought I’d ask the devs - should any of these really be in production logs? Or is this something that could be cleaned up so GeoServer starts clean?

I have a similar JIRA issue open about the initial release configuration, more about useful example/defaults.

This would be a good thing to target for 2.5 … if you think we can crush these warnings by next release. You may want to put this forward as a GSIP since it would require collaboration across a number of modules.

Jody

Hi Jody,
Thanks for your Input.

There are two reasons why WKT would be used:
a) one of your layers uses an “prj” file - in which case this warning is fair
b) geoserver, or your installation, includes additional custom definitions in an epsg.properties files - in which case this warning is far. However for the “built-in” additional codes we can probably suppress these warnings while parsing the file.

We’re not using EPSG:54004 - everything is in 27700.
I’ve never touched epsg.properties, or created a custom definition so I believe this is a problem with stock geoserver.
Deleting that entry from the epsg.properties doesn’t seem to stop that error from appearing in the log.

2013-12-17 06:05:15,128 WARN [org.geoserver] - Ignoring store directory ‘layergroups’

2013-12-17 06:05:15,331 WARN [org.geoserver] - Ignoring store directory ‘styles’

Not sure either, something to fix in code or configuration?

There are five directories called “styles” and three called “layergroups” in my data directory - all of them are used/created by GeoServer for storing config stuff. It’s not clear from the error which of these that the error is complaining about.

If it is configuration, the error should be clearer for the user as to what they’ve done wrong.

This would be a good thing to target for 2.5 … if you think we can crush these warnings by next release. You may want to put this forward as a GSIP since it would require collaboration across a number of modules.

Assuming a GSIP is what I think it is, that’s kind of what I was thinking too. I can write one if desired, though some pointers would be good as I’ve not done one before.

Regards,
Jonathan

On 17 December 2013 21:52, Jody Garnett <jody.garnett@anonymised.com> wrote:

I am sure this list can be toned down, and I like the goal of making “GeoServer start clean”.

Lets have a look…

2013-12-17 06:05:01,509 WARN [support.DisposableBeanAdapter] - Invocation of destroy method failed on bean with name ‘geoServerLoader’: org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean with name ‘GWCLifeCycleHandler’: Singleton bean creation not allowed while the singletons of this factory are in destruction (Do not request a bean from a BeanFactory in a destroy method implementation!)

This looks to be a mistake that can be cleaned up.

2013-12-17 06:05:02,336 WARN [referencing.factory] - Axis elements found in a wkt definition, the force longitude first axis order hint might not be respected:

PROJCS[“WGS84 / Simple Mercator”, GEOGCS[“WGS 84”, DATUM[“WGS_1984”, SPHEROID[“WGS_1984”, 6378137.0, 298.257223563]], PRIMEM[“Greenwich”, 0.0], UNIT[“degree”, 0.017453292519943295]], PROJECTION[“Mercator_1SP_Google”], PARAMETER[“latitude_of_origin”, 0.0], PARAMETER[“central_meridian”, 0.0], PARAMETER[“scale_factor”, 1.0], PARAMETER[“false_easting”, 0.0], PARAMETER[“false_northing”, 0.0], UNIT[“m”, 1.0], AXIS[“x”, EAST], AXIS[“y”, NORTH], AUTHORITY[“EPSG”,“54004”]]

There are two reasons why WKT would be used:
a) one of your layers uses an “prj” file - in which case this warning is fair
b) geoserver, or your installation, includes additional custom definitions in an epsg.properties files - in which case this warning is far. However for the “built-in” additional codes we can probably suppress these warnings while parsing the file.

2013-12-17 06:05:10,479 WARN [geoserver.logging] - Suppressing StdOut logging. If you want to see GeoServer logs, be sure to look in ‘C:\Tomcat_Compass\bin..\instances\instance1\logs\GeoServer.log’

I expect this could be set to INFO.

2013-12-17 06:05:11,883 WARN [config.CustomEditorConfigurer] - Passing PropertyEditor instances into CustomEditorConfigurer is deprecated: use PropertyEditorRegistrars or PropertyEditor class names instead. Offending key [org.geotools.util.Version; offending editor instance: org.geoserver.platform.util.VersionPropertyEditor@anonymised.com

Looks to be something to fix.

2013-12-17 06:05:13,677 WARN [referencing.factory] - Axis elements found in a wkt definition, the force longitude first axis order hint might not be respected:

PROJCS[“WGS84 / Simple Mercator”, GEOGCS[“WGS 84”, DATUM[“WGS_1984”, SPHEROID[“WGS_1984”, 6378137.0, 298.257223563]], PRIMEM[“Greenwich”, 0.0], UNIT[“degree”, 0.017453292519943295]], PROJECTION[“Mercator_1SP_Google”], PARAMETER[“latitude_of_origin”, 0.0], PARAMETER[“central_meridian”, 0.0], PARAMETER[“scale_factor”, 1.0], PARAMETER[“false_easting”, 0.0], PARAMETER[“false_northing”, 0.0], UNIT[“m”, 1.0], AXIS[“x”, EAST], AXIS[“y”, NORTH], AUTHORITY[“EPSG”,“54004”]]

(I’m not even using that projection!)

Same deal as above, you can remove it from your data directory epsg.properties file if you are not using it.

2013-12-17 06:05:15,128 WARN [org.geoserver] - Ignoring store directory ‘layergroups’

2013-12-17 06:05:15,331 WARN [org.geoserver] - Ignoring store directory ‘styles’

Not sure either, something to fix in code or configuration?

2013-12-17 06:05:15,331 WARN [org.geoserver] - Ignoring store directory ‘Oracle Live - OSMM’
2013-12-17 06:05:15,331 WARN [org.geoserver] - Ignoring store directory ‘layergroups’
2013-12-17 06:05:18,170 WARN [org.geoserver] - Ignoring store directory ‘styles’

I don’t think any of the above sets of logging should be in Production logs at all.

I think we should clean up our example configuration so they do not occur, so if these warnings are useful in a production setting they will be respected.

And then there’s a list of every single layer telling me that I don’t have a primary key set in my Oracle (I know):

2013-12-17 06:05:30,899 WARN [geotools.jdbc] - Failure occurred while looking up the primary key with finder: org.geotools.jdbc.HeuristicPrimaryKeyFinder@anonymised.com
2013-12-17 06:05:30,899 WARN [geotools.jdbc] - No primary key or unique index found for OS_MM_CARTOGRAPHIC_SYMBOL.
2013-12-17 06:05:31,040 WARN [geotools.jdbc] - Unrecognized geometry type DEFAULT falling back on generic ‘GEOMETRY’

Ideally that wouldn’t be in there either, but can understand the case for why it could be.

Think we could make an extra connection parameter here, the default setting can produce the warnings, and provide an explicit setting to handle the “I know” case.

Rather than just unilaterally opening a JIRA, I thought I’d ask the devs - should any of these really be in production logs? Or is this something that could be cleaned up so GeoServer starts clean?

I have a similar JIRA issue open about the initial release configuration, more about useful example/defaults.

This would be a good thing to target for 2.5 … if you think we can crush these warnings by next release. You may want to put this forward as a GSIP since it would require collaboration across a number of modules.

Jody

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

On Wed, Dec 18, 2013 at 12:53 PM, Jonathan Moules <
jonathanmoules@anonymised.com> wrote:

Assuming a GSIP is what I think it is, that's kind of what I was thinking
too. I can write one if desired, though some pointers would be good as I've
not done one before.

You'll need to get a Confluence access, and look at the previous ones as
examples.
But mind, a the objective of a GSIP is twofold: on one side, describe
changes that you want to implement, on the other, ensure that
you have the coding/testing resources necessary to pull off the changes you
described

Cheers
Andrea

--
*== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to
06/01/2014 ==*

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

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

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

Ah right, kind of a lot beyond me an my knowledge of GeoServer then. Anyone else want to volunteer? :slight_smile:

Thanks,
Jonathan

But mind, a the objective of a GSIP is twofold: on one side, describe changes that you want to implement, on the other, ensure that
you have the coding/testing resources necessary to pull off the changes you described

Further to this, another few potentials for lowering of the logging level:

This seems to happen in response to WFS GetCapabilities requests from QGIS:

2014-01-14 10:05:32,294 ERROR [geoserver.wfs] - ERROR IN class org.geoserver.wfs.response.Excel97OutputFormat IMPLEMENTATION. getCapabilitiesElementName() should return avalid XML element name string for use in the WFS 1.0.0 capabilities document.
2014-01-14 10:05:32,294 ERROR [geoserver.wfs] - ERROR IN class org.geoserver.wfs.response.Excel2007OutputFormat IMPLEMENTATION. getCapabilitiesElementName() should return avalid XML element name string for use in the WFS 1.0.0 capabilities document.
2014-01-14 10:05:32,294 ERROR [geoserver.wfs] - ERROR IN class org.geoserver.kml.WFSKMLOutputFormat IMPLEMENTATION. getCapabilitiesElementName() should return avalid XML element name string for use in the WFS 1.0.0 capabilities document.

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

========

No Idea what caused these two, but they don’t look like they’re something I as a server admin would want to know or could do anything about.

On 18 December 2013 13:35, Jonathan Moules <jonathanmoules@anonymised.com> wrote:

2014-01-14 10:05:46,942 WARN [wms.capabilities] - Map output format text/html does not include mime type in output format names. Will be excluded from capabilities document.
2014-01-14 10:05:46,942 WARN [wms.capabilities] - Map output format application/xml does not include mime type in output format names. Will be excluded from capabilities document.

========

Like the no legend, it seems querying the unqueryably brings up an ERROR level event. Could be INFO or similar.

2014-01-14 12:17:50,914 ERROR [geoserver.ows] -
org.geoserver.platform.ServiceException: Layer Public_Data_DB:OS_MM_TOPOGRAPHIC_AREA is not queryable
at org.geoserver.wms.featureinfo.GetFeatureInfoKvpReader.read(GetFeatureInfoKvpReader.java:119)

Cheers,
Jonathan

Ah right, kind of a lot beyond me an my knowledge of GeoServer then. Anyone else want to volunteer? :slight_smile:

Thanks,
Jonathan

But mind, a the objective of a GSIP is twofold: on one side, describe changes that you want to implement, on the other, ensure that
you have the coding/testing resources necessary to pull off the changes you described