Dies,
I think it is better to provide a log format similar to access
log format. Are there any standard formats in this regard? (I guess
server.log is not as "common" or uniform as access log and hence
it is probably difficult to have a pseudo standard for this).
Regarding ID's:
In all the GF releases, all log messages are supposed to
have a unique identifier. Thus, everyone should provide messages
(in LogStrings.properties) that have unique identifiers. Somehow,
what happens is developers log strings from LocalStrings.properties
which are supposed to be for localization of exception messages.
Thus, if the code is something like:
String msg = LocalStringManager.get("password.invalid");
Logger log = getLogger();
log.info(msg);
then all such messages won't have any identifiers. So, the key is
developers should not mix LogStrings.properties and LocalStrings.properties.
I am not sure if logging infrastructure itself can do anything about
this. It's a developer's judgment call.
-Kedar
Dies Koper wrote:
> Hi,
>
> Thank you for your reply.
>
> I will keep preparing patches when I run into issues with parameters
> that are not substituted and messages that are not logged.
> For the other issues, I would like to make a consensus here first. It
> will take some time to prepare the patches so I want to make sure
> everybody agrees with them.
>
> I saw Jan mentioning that he wants to retire the PWC error numbers and
> not add any new ones in the webtier ML. I'm not sure whether that just
> referred to particular messages in a particular message file or all.
>
> May I ask more people for their opinions?
>
>>> 3. Some messages have an ID (WEB7000, etc.), some don't.
>>> We think it is useful for messages to have an ID for the following
>>> reasons:
>>> - When looking in the log file, it makes it easier to see which
>>> messages are logged by GF and which by the application.
>>> - It is easier to communicate with others (colleagues in the next
>>> cubicle, on the phone, etc.) when discussing an error message when it
>>> has a simple ID.
>>> - It makes it easier to google an issue (if you copy & paste the whole
>>> message you might unintentionally include its parameters, reducing
>>> the hits)
>>> - It makes it easier to analyze the log file, monitor it and watch for
>>> certain messages using an external tool.
>>> -> Are there any rules or guidelines on this?
>>
>> There were around 5 years ago, when the person then working on logging
>> helped to establish the conventions. I'm not sure if I can find a
>> copy of the
>> document (probably written by Hemanth Puttaswamy, who is no longer at
>> Sun),
>> but it's probably available somewhere, possibly on one of the internal
>> to Sun
>> pre-GlassFish servers.
>
> In absence of the original document, may I propose the following
> convention regarding message ID's?
>
> 1. All following messages should have an ID:
> - messages logged with level INFO, WARNING or ERROR (i.e. no need for
> ID's in debugging messages)
> - messages logged to server.log or the acc log (i.e. no need for ID's
> in exception messages)
>
> 2. ID's should be of the following format:
> - '\w+\d+', in other words, some letters followed by some digits.
> I have seen ID's of various lengths with regard to the number of
> letters and digits, and there is no need to put restrictions on it.
>
> 3. ID's should be unique within a module and within a GlassFish version.
>
> 4. ID's and messages are separated by a colon (':'), with the colon
> optionally surrounded by a single space.
> I've seen many cases where a single space is used before and/or after
> the colon, so it'll be easier to include it in the convention.
>
>>> 5. Typos in messages. In most cases it is not difficult to understand
>>> what is meant. It just looks bad. I use Eclipse as IDE and it has a
>>> spell checker built-in, so it is easy to see where the spelling mistakes
>>> are (they are underlined in red).
>>>
>>
>> Keep the patches coming! This is a pretty low overhead way to clean
>> up the
>> product, in ways that support anyone writing tools to scan log files.
>
> I think so too.
> But is everybody OK with fixing message texts? Does it cause problems
> when googling them on the web (cannot find old posts from users who ran
> into similar trouble but posted the old message)? I suppose the search
> engines are smart enough to find them still..
>
> Thanks,
> Dies
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>