On Mon, Aug 17, 2015 at 12:10 PM, Wittle, Paul <P.Wittle@anonymised.com>
wrote:
Hi,
I'm trying to improve my GeoServer logging and I can't see any
instructions online to deal with the 'Could not find layer' log entries.
If I make an incorrect request for a layer which doesn't exist it
generates a ServiceException and this includes a log entry which is flagged
as an 'ERROR' and includes a stack trace with over 100 lines of text. We
use OpenLayers so if a layer is misconfigured you can get an idea of how
much this clogs up the log file.
Given that I am using PRODUCTION logging I would like to limit this
particular log entry to a single line (or two if required). My ideal log
entry would be:
"2015-08-17 10:52:49,350 INFO [geoserver.ows] -
org.geoserver.platform.ServiceException: Could not find layer
workspace:layername"
I'm aware that others may want it recorded as an ERROR but for me I don't
want it to do that unless I switch to a different logging level (i.e. DEBUG
or VERBOSE) for that particular error. To me, this is an incorrect user
request it is not an actual error in GeoServer; I doubt it is handled in
the same way if you do a catalog query?
Is there a way to set how particular errors are handled in the logging
settings or are the settings limited to filtering on error type only?
There is almost no distinction between user and internal error inside
GeoServer. I say almost because some errors end up being wrapped
in an exception with a OGC specific code, which can in some cases be used
to infer that an error is a user error.
These users codes are spread out in the code base and are OGC version and
protocol dependent, which makes things somewhat harder.
The exception logger is centralized, it gets all exceptions, and already
tries not to log the ones that originate from a client
closing the HTTP connection in GeoServer face, but that's all.
With some refactoring we could indeed have that centralized logger tone
down the user errors that are immediate to be recognized,
at least a few ones, and then over time classify the exceptions better so
that more and more user are recognized as such.
E.g. if I'm guessing correctly your error is created as:
throw new ServiceException("Could not find layer " + layerName,
"LayerNotDefined", "layers");
We would have to refactor that string into an enumeration of sort, mark the
enumeration entries
as being (or not) user errors, and then modify the Dispatcher so that it
can recognize the user
errors. As said, what makes it annoying is that across the various
protocols we have usage of
free strings (in the oldest, like WMS above), strings backed by constants,
and custom made enums,
like in WCS 2.0 where we have a HTTP code associate by spec with each
exception class
(fun fact, that is not shared wtih WCS 1.0 and 1.1... which use strings
instead).
Welcome to the pleasure of working against a 13 years old codebase 
Cheers
Andrea
--
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
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
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
-------------------------------------------------------