Hi,
a failing maven build on trunk is a pain these days... it's a
pain because unit tests are generating that much log that it's
not even possible to see in which module the test failed (I
don't have that much scrollback).
The output looks like:
...
INFO:
Request: getFeature
handle = null
service = WFS
version = 1.1.0
query = [net.opengis.wfs.impl.QueryTypeImpl@anonymised.com (group: null, propertyName: null, function: null, filter: [ Seven.0 ], sortBy: null, featureVersion: null, handle: null, srsName: urn:x-ogc:def:crs:EPSG:6.11.2:4326, typeName: [{http://www.opengis.net/cite/data\}Seven])]
maxFeatures = null
outputFormat = text/xml; subtype=gml/3.1.1
resultType = results
traverseXlinkDepth = null
traverseXlinkExpiry = null
Result:
31-lug-2007 12.21.19 org.vfny.geoserver.global.GeoserverDataDirectory init
GRAVE:
----------------------------------
- GEOSERVER_DATA_DIR: C:\DOCUME~1\ADMINI~1\IMPOST~1\Temp\mock61343data
----------------------------------
31-lug-2007 12.21.19 org.vfny.geoserver.global.xml.XMLConfigReader loadCatalog
AVVERTENZA: Your catalog.xml file is not up to date and is probably from an older version of GeoServer. This problem is now being fixed automatically.
31-lug-2007 12.21.19 org.vfny.geoserver.global.GeoServer configureGeoServerLogging
INFO: CONFIGURING GEOSERVER LOGGING -------------------------
31-lug-2007 12.21.19 org.vfny.geoserver.global.GeoServer isGeoserverControllingLogging
AVVERTENZA: No 'commons-logging.properties' found on GeoServer's classpath. GeoServer
31-lug-2007 12.21.19 org.vfny.geoserver.global.GeoServer configureGeoServerLogging
AVVERTENZA: GeoServer isn't controlling the logging system.
31-lug-2007 12.21.20 org.geoserver.wfs.WFSLogger invoke
INFO:
Request: getFeature
handle = null
service = WFS
version = 1.1.0
query = [net.opengis.wfs.impl.QueryTypeImpl@anonymised.com (group: null, propertyName: [string2], function: null, filter: null, sortBy: null, featureVersion: null, handle: null, srsName: null, typeName: [{http://www.opengis.net/cite/data\}Other])]
maxFeatures = null
outputFormat = text/xml; subtype=gml/3.1.1
resultType = results
traverseXlinkDepth = null
traverseXlinkExpiry = null
repeated over and over... I guess we should disable console logging completely during unit tests, and eventually have a system variable
allowing to choose a certain logging configuration? So that during
interactive tests console logs can be seen, that is.
Btw, the tests failure in my case was related to an already existing
mockxxxx directory in my temp folder that was messing up the tests...
we should really really make sure all of them are removed.
We should start with an empty temp directory and end with another
empty one, regardless of whether tests did succeed or fail.
Cheers
Andrea
repeated over and over... I guess we should disable console logging completely during unit tests, and eventually have a system variable
allowing to choose a certain logging configuration? So that during
interactive tests console logs can be seen, that is.
Hmm... some of the console logs are useful though when debugging a unit tests that is failing. There are however some logs that can be committed safely. Like the logs about configuring logging and the data directory.
Could we possibly come up with a custom log4j.properties for units tests which could disable these specific logs... and any others we don't want.
Btw, the tests failure in my case was related to an already existing
mockxxxx directory in my temp folder that was messing up the tests...
we should really really make sure all of them are removed.
We should start with an empty temp directory and end with another
empty one, regardless of whether tests did succeed or fail.
Does this happen every time? The setup / teardown is careful about making sure it does delete all the files... however its possible that something is being missed.
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,46af1217135362458217002!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
repeated over and over... I guess we should disable console logging completely during unit tests, and eventually have a system variable
allowing to choose a certain logging configuration? So that during
interactive tests console logs can be seen, that is.
Hmm... some of the console logs are useful though when debugging a unit tests that is failing. There are however some logs that can be committed safely. Like the logs about configuring logging and the data directory.
Could we possibly come up with a custom log4j.properties for units tests which could disable these specific logs... and any others we don't want.
Hum, yeah, that could be an option as well.
Btw, the tests failure in my case was related to an already existing
mockxxxx directory in my temp folder that was messing up the tests...
we should really really make sure all of them are removed.
We should start with an empty temp directory and end with another
empty one, regardless of whether tests did succeed or fail.
Does this happen every time? The setup / teardown is careful about making sure it does delete all the files... however its possible that something is being missed.
Nope, it has happened to me twice so far but randomly. I wiped out
temp this morning, after a few trunk builds its current contents are:
31/07/2007 12.38 <DIR> mock18664data
31/07/2007 12.38 <DIR> mock18665data
31/07/2007 12.38 <DIR> mock18666data
31/07/2007 12.38 <DIR> mock18672data
31/07/2007 17.11 <DIR> mock2684data
31/07/2007 12.36 <DIR> mock33862data
31/07/2007 12.36 <DIR> mock33872data
31/07/2007 12.36 <DIR> mock33874data
31/07/2007 12.36 <DIR> mock33876data
31/07/2007 12.36 <DIR> mock33885data
31/07/2007 12.37 <DIR> mock33916data
31/07/2007 17.12 <DIR> mock35750data
31/07/2007 17.12 <DIR> mock47496data
31/07/2007 17.12 <DIR> mock47511data
31/07/2007 17.12 <DIR> mock47512data
31/07/2007 17.12 <DIR> mock47513data
31/07/2007 17.12 <DIR> mock47519data
31/07/2007 12.52 <DIR> mock58984data
31/07/2007 12.52 <DIR> mock58999data
31/07/2007 12.52 <DIR> mock59000data
31/07/2007 12.52 <DIR> mock59001data
31/07/2007 12.52 <DIR> mock59007data
31/07/2007 12.38 <DIR> mock59478data
So I guess there are in fact some mock dirs that aren't getting
deleted. Can you look into your temp? Maybe it's a platform dependent
issue.
Cheers
Andrea