Salut,
Dies Koper wrote:
> Hi,
>
> Earlier this week I sent an e-mail (included below) to the GF dev ML to
> discuss the improvement of messages. One of the issues I found is the
> inconsistency in message IDs of the messages logged in server.log.
>
> I am hoping to get a consensus on the use of message IDs, and then
> provide patches.
>
> We can achieve maximum benefit of this work if other projects used in
> GlassFish follow a compatible convention for their messages.
>
> I have already received some responses from GF developers.
> I would be very interested in yours too.
Ok I will.
>
> Particularly, I noticed a message properties file in Grizzly, which had
> exactly the same messages as a message properties file in GlassFish, but
> in Grizzly's all message IDs were removed. You chose that it is better
> to not have them? Why?
Because the number where not making any sense, and I hated seeing PWC as
it doesn't mean anything. I'm not against using number for Grizzly, but
following the GlassFish numbering/naming scheme is not something I would
do.
>
> Could you please join this thread in the GF dev ML, or reply to my
> e-mail here?
> http://www.nabble.com/patches-to-fix-format-of-messages-in-server-log-td21783192.html
OK will do as soon as I can.
Thanks!
-- Jeanfrancois
>
>
> Thanks!
> Dies
>
>
> -------- Original Message --------
> Subject: patches to fix format of messages in server log
> Date: Mon, 2 Feb 2009 13:34:47 +1100
> From: Dies Koper <diesk_at_fast.au.fujitsu.com>
> Reply-To: dev_at_glassfish.dev.java.net
> To: <dev_at_glassfish.dev.java.net>
>
> Hi,
>
> We've noticed a number of what we think are issues with some of the
> messages logged to server.log.
> I'd like to provide patches to fix them, but before I do that I'd like
> to confirm that you agree they are indeed issues and would be interested
> in fixing them.
> (If the rules for GF messages have been written down or discussed
> somewhere, I'll read it first. I'd be grateful for a link!)
>
> 1. Some messages are not defined or defined in the wrong log file,
> leading to the message key to be logged instead.
> -> I'm sure you'll be interested in these issues? Some of my patches
> for such issues have already been accepted.
>
> 2. Some parameters included in messages include arguments but they are
> not substituted correctly. (leading to {0} in messages)
> -> I'm sure you'll be interested in these issues too? Some of my
> patches for such issues have already been accepted.
>
> 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?
>
> 4. Most messages that are logged with an ID, are logged with a format
> 'XXXnnnn: MSG', where XXX is an ID indicating the component where the
> message is logged, and nnnn a number. Some messages however don't follow
> this layout. I've seen ID like 'RAR 1000:' (whitespace in ID),
> '"DPL8012:' (double quotes around the whole message), or none, one or
> more spaces before and after the ':' separating the message from the ID.
>
> 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).
>
> Thanks,
> Dies Koper
> This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN
> 27 003 693 481. It is confidential to the ordinary user of the email
> address to which it was addressed and may contain copyright and/or
> legally privileged information. No one else may read, print, store, copy
> or forward all or any of it or its attachments. If you receive this
> email in error, please return to sender. Thank you.
>
> If you do not wish to receive commercial email messages from Fujitsu
> Australia Software Technology Pty Ltd, please email
> unsubscribe_at_fast.fujitsu.com.au
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>