Hi Carla,
> Message ids can not have a space as that will cause an exception when we
> try to use the message id as a key.
I noticed a whole bunch of CLI messages with no colon between message ID
and message text. I suppose CLI messages won't go to the log viewer, but
still for consistency I can put the colon in there. What do you think?
> If you would like to help that would be great. I know that Sekhar was
> compiling a list of messages and ids that should be added but I don't
It's the following, isn't it?
http://wiki.glassfish.java.net/attach/GlassFishV3LoggingServiceability/msgidlist.html
> have that list. the thing that needs to be done when adding the message
> ids is to figure out which logger is used and make sure that the message
> id is unique in the package where it is used. Sekhar and I thought it
> would be easiest to just assign a range of numbers for each module
> (actually logger from LogDomains) and that would minimize duplicates. I
> can publish that list tomorrow.
That would be great.
> Let me know if you have questions.
1. How to assign/determine the 6 character component name part of the
message ID?
For example, none of the messages in the following property files
have an ID yet.
flashlight\LogStrings.properties
flashlight\impl\client\LogStrings.properties
flashlight\impl\provider\LogStrings.properties
flashlight\xml\LogStrings.properties
The messages are logged with the following logger:
MONITORING_LOGGER=DOMAIN_ROOT + "enterprise.system.tools.monitor";
Could you include the 6 character component name parts in that list?
2. Who can review/approve my changes?
Do I need to ask each module owner? If so, how do I find out the
owner for example the 'flashlight' files above?
I searched the following page but it's not there. Also checked the
pom.xml's but no <developer> elements defined.
http://wiki.glassfish.java.net/Wiki.jsp?page=ModulesAndLeads
3. Is it okay to add ID's to messages of all levels or do I need to look
up the message keys in the code to check the level. What if it's INFO?
Can I add it at my own discretion? (of course reviewer can double-check)
4. When I do check the message level and find it's FINE/FINEST, shall I
move the message back from message file to source code?
I found one of these in JDBC and just e-mailed Shalini about it.
I prefer hard-coding of FINE messages because I think these messages
are mostly for debugging by/for GF developers, so we need them to be in
English. (Imagine the trouble you'd be in if the message were logged in
Chinese and a user pasted it in the user mailing list asking for help:
Without a message ID you'd have no idea what message it is! (unless you
read Chinese of course)).
This is b.t.w. another argument for adding message IDs to all INFO
messages too.
5. What do I do with messages that don't seem to be used anymore (can't
find them when I try to grep them in source). Delete and let the
reviewer make the final call?
Sorry for the detailed questions. I don't want to fix them without
consensus and risk not getting my patches approved :)
Thanks,
Dies
> Gail Risdal wrote:
>> Hi Dies,
>>
>> One other thing ...
>>
>> I just heard back from the doc tools developer, who says #3 and #4 in
>> your list would break the tool we're using to harvest the error
>> messages for the documentation.
>>
>> Thanks,
>> Gail
>>
>> Dies Koper wrote:
>>> Hi,
>>>
>>> We had several threads about the messages: that they need message IDs,
>>> diag info and (not much discussed) be externalized for localization.
>>> Sekhar has even prepared a tool to help.
>>>
>>> Since then I think everybody has been too busy to actually do the work.
>>>
>>> I'd like to help out where I can, and already sent out a patch to
>>> Shalini directly for jdbc, but felt we still have different opinions
>>> about what to do. I'd like to move the discussion here to explain my
>>> intentions so that all the module owners for whom I might prepare
>>> similar patches are in agreement with it.
>>>
>>> For now, I'd like to fix the following issues:
>>>
>>> 1. Messages with no ID
>>>
>>> 2. Typos (just the obvious ones, I'm not a professional proofreader)
>>>
>>> 3. Message ID (layout) issues (such as space in "RAR 7014")
>>>
>>> 4. Single apostrophes in messages with arguments (see issue #9896)
>>>
>>> For most messages I can't supply the diag info, it would take too much
>>> time to investigate each and find meaningful check/cause explanations.
>>> Is that okay?
>>>
>>> Although from the discussions I understood that message IDs on INFO
>>> messages are "not required", I did not take it to mean INFO messages
>>> CANNOT have IDs. In many cases it will be easier for me to just add IDs
>>> to all messages, as cross-referencing with the logging code to check the
>>> level would take a lot of time. Is that okay?
>>> (Of course I would be careful not to add IDs to messages that should not
>>> have IDs, and you'll have a chance to double-check when you review the
>>> patches.)
>>>
>>> Also, it is my understanding that the doc team will run a tool at the
>>> end to pick up all messages from the property files, so I do not need to
>>> worry about updating the docs. Is that correct?
>>>
>>> Thanks,
>>> Dies
>>>