Sorry for a long response, but the subject mandates it.
Short answer:
- it is better to stick to format number 1 that is an ID for a logged record.
- it is better to have an API to parse the collection of log-records. Lack
of such an API results in bugs/rfe's like:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6438036
Long answer regarding why we have a mix and match:
Several months ago, this issue had come up in a discussion around something
called a "Trouble Shooting Guide".
Quoting from there ....
<snip>
- The "challenges section" puts yet another onus on Engineering. Currently, if
you look at a recent 9.0 build, you'd find message like the following appear there:
----------------------------------------------------------------
[#|2005-11-03T05:29:03.175-0800|INFO|sun-appserver-ee9.0|javax.enterprise.resource.jms|_ThreadID=10;_ThreadName=main;|Using
MQ RA for Broker lifecycle control|#]
[#|2005-11-03T05:29:04.581-0800|INFO|sun-appserver-ee9.0|javax.enterprise.system.tools.admin|_ThreadID=10;_ThreadName=main;|ADM0001:MBeanServer
initialized successfully|#]
[#|2005-11-03T05:29:09.163-0800|INFO|sun-appserver-ee9.0|javax.enterprise.system.core.security|_ThreadID=10;_ThreadName=main;com.sun.enterprise.security.provider.PolicyWrapper;|SEC1143:
Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.|#]
[#|2005-11-03T05:29:09.312-0800|INFO|sun-appserver-ee9.0|javax.enterprise.system.core.selfmanagement|_ThreadID=10;_ThreadName=main;|sgmt.service_initialized|#]
----------------------------------------------------------------
...
Now, some of the messages have a unique ID and some of them don't. And if you
dig further, there is a mix of such messages all-over. The issue has its reasons
is apparent confusion among developers between "What should be logged and what
should be returned to the calling code in terms of exceptions". Also, the
exception messages are supposed to be coming from a file named
"Localstrings.properties" whereas the logged strings are coming from a file
(placed elsewhere :( ) named "LogStrings.properties". The semantics of logging
and creating "localized" strings are significantly different. Apparently, the
LocalStrings stuff works better than the LogStrings stuff and developers tend to
log "free-form" messages to the server's log file (which then end up in Log Viewer).
One of the ways to tackle this problem is to set up an "Engineering Task
Force" that painstakingly finds these discrepancies and gets them corrected.
This is certainly not a one-person-job, IMO.
- The discussion in your document is centered around "GUI Log Viewer". We should
extend it to the command line interface. After all, we need to have a command
(we are thinking about it) in our CLI that does something similar to the Log
Viewer. So, the content of Error Messages Document and coding around it is a
necessity. For example, it is useful to have something like:
asadmin diagnose-error [--detailed] <keywords including ID>
will be immensely useful, where the operand of the command is a keyword and/or
an ID.
If you say you'd like to maintain one document "live" on the web, it is almost
imperative that we have an API that can get the data from this document for CLI
purposes.
- Regarding maintaining this document online: I feel that although it is more
efficient to do so than bundling it in the product, the latter is still
necessary for it may be the case that online content is not available at times
either for a network failure or for the downtime of docs.sun.com. This also
brings up another point about the manpages and their access from a client
machine where "asadmin" is being run. There are a few details about this at:
http://appserver.sfbay.sun.com/apollo/admininfra/structure/discussions/cli-documentation.html
. We'd like to know what docs team thinks about it.
</snip>
The last link is within Sun Intranet and hence I have made it available at:
http://wiki.java.net/bin/view/Projects/ImprovingAsadminDocumentation
The bottom line: it is the question of using the right file that contains the
loggable records. Don't use the i18n'ed Strings from "LocalStrings.properties".
They are not for logging purposes.
Kedar
vince kraemer wrote:
> I am wondering if there is a "standard" format for error messages in the
> log...
>
> It seems like there is a couple different standards at play today.
>
> For example, I see messages like:
>
> [#|2006-07-15T09:54:59.148-0700|INFO|sun-appserver-pe9.0|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|CORE5098:
> AS Socket Service Initialization has been completed.|#]
>
> and messages like:
>
> [#|2006-07-15T09:54:57.488-0700|INFO|sun-appserver-pe9.0|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Starting
> Sun Java System Application Server Platform Edition 9.0 (build b03) ...|#]
>
> The first message is "nice" for automation, since it has an identifier
> (CORE5098).
>
> The second isn't so friendly to automation.
>
> Which message is "correct"?
>
> Since messages show up in the log and their source module might not be
> evident, how should we handle filing issues for poor [unhelpful] or
> incorrect [non-standard] messages?
>
> vbk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>