Hi Sekhar,
Firstly, I think it's great that you've written this tool and have
included all modules' message property files in the V3 workspace.
I hope once the color coding, etc. has been sorted out you will share
this tool with developers from the other projects used in GlassFish
(Grizzly, OpenMQ, hk2, etc.) to help them check and fix their messages too.
As one of the lucky 95% with proper color vision I took a look at your
posted results.
I think the good thing about not splitting up the now red and green
messages is that you don't loose context. Maybe you could use light gray
for messages with ID (as they're done, they don't need to stand out),
and normal black for the others?
Secondly, your tool also made a few (potential) bugs in current messages
visible. I hope the developers will address them as they go through them.
For example:
- "JTS5027.diag1.check.1" should probably be "JTS5027.diag.check.1"
(diag/cause counter should only be at the end of the key name) to be
picked up by the log viewer.
- "pemain.error"'s message has an old product name in it ("Could not
start S1AS PE 8 Server : {0}"). Old message? Old code?
- "RAR 7014" has space in its ID.
- "RAR 7014" is defined in multiple message bundles. (or maybe the same
message bundle is stored in multiple modules). Is that intentional?
- " default-jms-host.": This part actually belongs to the previous key's
message.
- "LDR5016", "SGMT0232", etc. has same problem as above.
- "mbean.instance_up:ADM1035" probably needs a '=' instead of a ':'.
- "registr.delete_org_succeeded" stands out as all previous messages
start with "registry.".
- "retrieve_client_stub_not_applicable" is the only key with its message
enclosed in double-quotes.
Great work!
Dies
Chandrasekhar Vajjhala wrote:
> Hi,
>
> To assist in locating and fixing messages with missing message ID, I wrote
> a tool. I ran the tool against the LogStrings.properties files in the
> GlassFish V3 workspace,
> and uploaded the output to GlassFish wiki page at [1] . I also linked
> [1] off the
> GlassFish Serviceability page [2] .
>
> Take a look at the the summary at the top of [1] for information on
> locating messages that need
> to be fixed, statistics on files, messages etc.
>
> Note:
> a. My workspace is about a couple of weeks old.
> b. I will rerun the tool periodically for now.
> c. I am looking into integrating the tool into GlassFish v3 build using
> maven.
>
> Sekhar
>
> [1]
> http://wiki.glassfish.java.net/attach/GlassFishV3LoggingServiceability/LogStrings-msgidlist.html?version=3
>
> [2]
> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3LoggingServiceability
>
>
> On 10/02/09 16:55, Jerome Dochez wrote:
>> Hi all
>>
>> Please review your modules for presence of logging activities at
>> SEVERE, WARNING, INFO levels with messages that are not
>> internationalized.
>> As you know all messages above INFO level must be internationalized.
>>
>> While you are at it, please review that such messages have a message
>> ID, see [1].
>>
>> If you find messages above INFO level which are not internationalized,
>> you must do either :
>>
>> 1. add the proper string lookup from the local strings.
>> 2. lower the level if the message is a necessity to the user's
>> understanding of the situation.
>>
>> I would rather see (1) of course.
>>
>>
>> Jerome
>>
>> [1]
>> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3LoggingMessageFormat
>>