Kedar,
Thanks for such a though response.
I want to make sure I have interpreted your responce to my questions
correctly, so, here is what I heard you say:
Kedar Mhaswade wrote:
> vince kraemer wrote:
>> I am wondering if there is a "standard" format for error messages in
>> the log...
I heard you say: No, but there should be; similar to the first example
logging message that you posted in this thread.
>>
>> 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"?
I heard you say: Both are "correct" at this time. The message with an
identifier is better and I would like it to be the only correct format.
>>
>> 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?
I did not really see/hear a clear response to this question in your
response. I might have missed it.
I think this is the question that needs discussion and action.
I know that there are a number of users, like Cay, that would love to
see us improved the error messages that end up in the log.
Most of those requests have been "filed" in the forums and in the
mailing lists. It would be nice to file them in something more
"trackable", like the issue tracker.
I have a couple more comments regarding your response, in-line...
>>
>> vbk
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
> 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.
Another way is to give the community a chance to contribute, by
establishing a process that is driven by their input.
I would recommend that we have:
1. a clear "Place" to file issues related to poor [unhelpful] and
illegal [messages that do not conform to the standard] messages in the log.
2. a way to collect user input regarding how important correcting a
message is; like the vote mechanism in the issue tracker.
3. some person/team that would cull though the filed issues and redirect
them to the right module for correction.
This would let the community "tell" the developers which messages need
to be corrected and which should be corrected first.
It could become a background thread for a modules contributors... got a
minute, make the user's life a little bit better.
vbk
>
> - 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
>