Timestamp format change has been committed to CoG log4j uitlity.

(In reply to comment #1)
> Timestamp format change has been committed to CoG log4j uitlity.

Can you be more specific?  What file (or files) have changed?  Thanks.

Changed:  src/org/globus/util/log4j/DatePatternConverter.java

Timestamp format is now set to YYYY-MM-DDTHH:MM:SS.SSSSSSZ (or) Z can be
replaced by +/-GMT. Example: 2007-05-01T16:34:47.292151-05:00

This has been committed only to CoG repository and not yet in Java WS Core. So
you should not see any changes in trunk GT components. If you use
org.globus.util.log4j.PatternLayout from JGlobus in some project for logging,
you will see the new timestamp format in your logs.

Created a branch: bug_5228_branch_1 for Java WS Components. Committed CoG jar
with new time format and a utility to format logging information as required by
the recommendation. 

http://viewcvs.globus.org/viewcvs.cgi/wsrf/java/core/source/src/org/globus/wsrf/utils/log4j/LogObject.java?revision=1.1.2.2&view=markup&pathrev=bug_5228_branch_1

Use the LogObject with appropriate parameters. Sample usage:

http://viewcvs.globus.org/viewcvs.cgi/wsrf/java/core/source/src/org/globus/wsrf/container/ServiceContainer.java?r1=1.70&r2=1.70.8.1&pathrev=bug_5228_branch_1


http://viewcvs.globus.org/viewcvs.cgi/wsrf/java/core/source/src/org/globus/wsrf/impl/security/authorization/AuthorizationHandler.java?revision=1.31.4.1&view=markup&pathrev=bug_5228_branch_1

Currently the formatting does not print line number, classname and method
information. this is required for developer level logs. But by default log4j
does not allow for per level pattern and this will require extending the
parser.
Also, core log statments need to be added. 

This work will take more than 1.5 days. Depending on whether the parser needs
to be extended it will be week's worth of work.

Added logging for all operation provider methods. 

Changed "date" to "ts".

Spruced up logging and sent out sample logs for comments. Based on feedback
following are required:

- ShutdownService and other core services need to provide logging
- Authn events need service name information
- Secure conversation requires start and end events

Also, separate tests for the LogObject classes need to be added

Added global id for use in logging. For every invocation that is made, a random
number is generated and stored as a MessageContext property.
(ServiceContainer.GLOBAL_LOG_ID). THe LogObject utility will automatically
append this to every logging statements, unless overridden by constructor.

Tests have been added for the utility code.

For now, the pattern class is not been extended. A sample converter with
classname/line number has been included and by default commented out.

To be compliant with CEDPs logging requirements and maintain the current
logging useful to developers, a separate logger for the system administrator
level logging was suggested. (Thanks to Martin Feller)

Such a support has been added in core. A class,
org.globus.wsrf.utils.log4j.SystemAdminLogFactory, has been added which has a
getLog() method. This will return a logger that appends "sysLogger" to the
name. 

private static Log logger =
           LogFactory.getLog(CounterService.class.getName());

private static Log sysLogger =
        SystemAdminLogFactory.getLog(CounterService.class.getName());

The usual logging with stack traces will remain as it is using the logger
object there. The sysLogger can be used for CEDPs compliant logging and the
LogObject utility should help there.

For example:

catch(RemoteException e)
        {
            sysLogger.error(new LogObject("org.samples.counter.create.end",
                                      "-1"));
            logger.error("Error creating counter", e);
            throw e;
        }

Any logging done using the system administrator logging will be written to
containerLog file in $GLOBUS_LOCATION. All other logging will remain as it is.

Ironed out issues with container logging and code has been merged with trunk.
Notes and sample log: http://www-unix.mcs.anl.gov/~ranantha/cedpsLogging/