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