Hi Dies,
Dies Koper wrote:
> 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?
Well, I want the message ids in the LogStrings.properties file because I
use them to get diagnostic info from the same file. The messages in
LocalStrings.properties don't go to the server log file and I don't
parse that file for more info. However, maybe someone in docs might
find that useful. For now I would prefer that we concentrate on the
LogStrings.properties file first.
>
>> 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
>
This is one of the first steps. See below.
>
>> 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?
To assign a message id you will need to figure out which logger is being
used. A module can use loggers that are not in their area. For
example a module may use the deployment logger. I have a list that
shows the prefix or the alpha characters for the different modules. It
is a bit old so the new stuff is not there but we can add that. Once
you have the prefix you need a number. Note that the message id must be
unique within a module. I was thinking that if we assign modules a
range of numbers then the prefix and the numbers together would
facilitate generating a unique message id.
In the case where the code is not using LogDomains to get the loggers
don't make a change.
I thought I had the ranges figured out and saw some messageids that had
numbers that I had missed. I need to rework the numbers.
> 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
these are part of monitoring and is new. We need to come up with a prefix.
>
> 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?
It would be great if the module owners can review in most cases. I
think the changes will be low risk but we still need to run quicklook
tests. The monitoring code is such that it needs to change to make use
of the LogStrings.properties file.
> 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)
>
we want to target SEVERE and WARNING first and then work on INFO.
> 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?
nope. I don't know why the FINE level messages are in the
LogStrings.properties file. Please write a bug.
> 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?
write a bug and let the developer clean it up.
>
> 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
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>