Hi Carla,
>> 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.
If each module gets its own unique alpha characters, why do you need to
assign number ranges to modules?
Why would a module use another's logger, and whose alpha characters
should its messages be using in this case?
> In the case where the code is not using LogDomains to get the loggers
> don't make a change.
Why? Don't they need to be in the manual?
>> 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.
You mentioned a max of 6 characters so "FLASH" seems a good pick.
>> 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.
Are you thinking of fixing Java code too? (moving from
LocalStrings.properties to LogStrings.properties?)
>> 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.
To do that I'd need to look up every message in the code. I've tried it
for a few and it took ages. Unless you can teach me a trick to do that
faster, I won't be able to help you as I can't spare that much more time
on it.
Besides, including INFO messages from the start would save us that time,
and I haven't heard a convincing argument yet against adding IDs to INFO
messages too. It just seems hopelessly inefficient.
>> 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 suppose they were first intended to have INFO level but were deemed
too 'chatty' and had their level reduced later.
>> 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.
It takes a lot of time to search for the level or use of messages. Then
writing an issue for it... If the developer has time to look at my
issues they might as well have a quick look at Sekhar's list and fix the
issues themselves. I don't see much value of my effort.
There are three other remaining issues we could start working on instead
that would give more bang for the buck:
1. Address the hard-coded warnings and errors (there's so many :()
2. Check and assist projects GF depends on inclusion of message IDs
(hk2, etc.).
3. Look at adding tasks to the build or QL process to automatically
check for these issues to prevent reintroduction of typos, ID-less
messages, hard-coded messages, etc.
Depending on the interest, after proper risk assessment some of 1. could
still be considered for inclusion in V3 post-HCF?
Regards,
Dies