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