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?
It should be easier to get unique numbers because you don't have to scan
the resource bundles (there may be more than one per module). I picked
numbers that were outside the range of numbers already in use.
>
>> 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?
You right they should go in the manual. In this case the messages will
not appear in the logs because we have a different algorithm for finding
the resource bundles (we override getResourceBundle). Not sure why some
code is not using GF's LogDomains.getLogger API. You should add them
and we can see how to fix that problem.
>
>>> 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.
OK. If the monitoring folks want a say they should suggest something.
>
>>> 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.
There is no trick. If it is easier to just do all of them.
>
>>> 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.
could be
>
>>> 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?
Yes. We were thinking about doing #3 after v3 fcs. All should be
considered for post v3 fcs.
Thanks,
Carla
>
> 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
>