Log implementation details
All information in GUMS is logged through the apache commons logging package.
The implementation used in GUMS is apache log4j. To change the logging
implementation you have to refer to the commons.logging implementation. Be aware
that some library that GUMS uses may not be as well behaved in regard to
logging.
The configuration is controlled by the log4j.properies file. This is a normal
log4j configuration file: refer to the log4j manual for more information.
GUMS using the follow conventions for log names:
- The developer's log uses one log for each different class, with the name
being the class name. Given GUMS package structure, "gov.bnl.gums" contains
the whole development log for GUMS. This allows the develop to filter the
log of the code he is working on.
- The admin log uses the log named "gums.resourceAdmin"
- The site security log is at "gums.siteAdmin"
Administrator's log
This log is meant for whoever is maintaining GUMS installation at a
particular site. The log is designed to be used in different ways: on standard
error, in a log file and in e-mails. E-mails will get from WARN up, the standard
error will receive from INFO up and the log can go down to TRACE. The breakdown
on the logging level is:
- FATAL - GUMS is unable to operate: no functionalities are available, and
the error condition cannot be recovered at runtime.
- ERROR - A particular operation failed or was incomplete. For example, the CMS VOMS
server couldn't be contacted, so it's members weren't refreshed (even though
the ATLAS group was); the NIS server didn't respond, so it is impossible to
generate the grid-mapfile for atlasgrid25, though the grid-mapfile for
atlasgrid26 could be generated since it doesn't require the NIS information.
Errors can be solved at runtime (i.e. modify the configuration file, restart
the database, etc...)
- WARN - A condition that hints to a misconfiguration or incorrect usage.
For example, a VO server returned no users.
- INFO - A normal operation has succeeded.
- DEBUG - Not used
- TRACE - Not used
Developer's log
The developer log is meant for someone developing the code or fixing bugs.
Each class will use the log named as their full class name. The breakdown on the
logging level is:
- FATAL - An exception or an inconsistency that forces GUMS to terminate
or not function at all. For example, a configuration file was not written
correctly or couldn't be found.
- ERROR - An exception or an inconsistency that doesn't allow GUMS to
complete a particular operation or part of it. For example, the CMS VOMS
server couldn't be contacted, so it's members weren't refreshed (even though
the ATLAS group was); the NIS server didn't respond, so it is impossible to
generate the grid-mapfile for atlasgrid25, though the grid-mapfile for
atlasgrid26 could be generated since it doesn't require the NIS information.
- WARN - An exception or an inconsistency that is not necessarily going to
affect functionalities, or an error condition that was recovered. For
example, a particular cache was found to be out of synch and was rebuilt.
- INFO - The successful completion of a macro-event (i.e. something that
happens only once in a while). For example, the configuration file was read,
the server was started. Typically used to debug configuration problems.
- DEBUG - The attempt or successful completion of a smaller event. For
example, a query was executed, a user was mapped. Typically one shouldn't
have more than one DEBUG statement in a method.
- TRACE - Shows the internal execution of the code. As a contrast,
building a query would be at this level. Inside method logging should be
done at this level
Site security log
The site security log will log all accesses.
- INFO - Will log all the "write" accesses
- DEBUG - Will log all the "read" accesses