Hi Dies,
There are (historical?) cases where a module uses loggers from another module(s)
in addition to its own logger, like CMP deployment uses deployment logger.
Regards,
-marina
Dies Koper wrote:
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>