Tom Mueller wrote:
> Naman,
> Thank you for this information. After reading through the referenced
> wiki page, I had a couple of questions.
>
> 1. When message ids are assigned to messages in LogStrings.properties,
> does the developer need to do anything else to notify anyone that this
> has been done. For example, do doc writers need to be informed that
> this message has to be documented? Or are new or changed messages
> automatically picked up by tools?
I believe that the docs folks have scripts that go through the
LogStrings.properties files and generate their info with each release.
They will automatically pick up new messages.
>
> 2. How does one get a new subsystem id to use for messages, while
> ensuring that it is unique?
This is the module owner's responsibility. He would figure out what
characters should be used to identify the current module and how the
numbers are assigned. For example, you could use ADMIN (this one is
already used) or ACONFIG or something else followed by a sequence of
numbers. Most of the time I have seen that modules use groups of
numbers for the different areas of their code. So a
LogStrings.properties file might have numbers starting with 0500 for a
set of messages and then jump to 0800 for example.
If you want to see the list of currently used subsystem ids I know that
the docs folks generate a doc with all the ids but I don't know the
pointer. Maybe Paul can help out.
Carla
>
> Thanks
> Tom
>
>
> On 5/26/2010 2:05 AM, Naman Mehta wrote:
>> Hi all,
>>
>> We are getting started with the 3.1 code and I wanted to send out a
>> note about logging messages in GlassFish v3.1.
>>
>> I wanted to make sure we all use the GlassFish logging mechanism as
>> it was intended. We have not changed the usage of logging in 3.1 from
>> 3.0.
>>
>> *
>> Specific Requirements for 3.1:*
>> 1. ALL messages of level SEVERE, WARNING and INFO must have a message
>> id. Log messages level SEVERE, WARNING and INFO should be in
>> LogStrings.properties file. All messages in the LogStrings.properties
>> file must have a message id. Please see the wiki page for information
>> on message ids:
>> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishV3LoggingMessageFormat
>> .
>>
>> 2. All SEVERE and WARNING messages must have diagnostic info too.
>> Below is an example I got from the EJB module. It shows the code and
>> the entries in the the LogStrings.properties file.
>>
>>
>> *Example code from EJB module: *
>> 1. Java File entry:
>> Logger _logger = LogDomains.getLogger(EJBSecurityManager.class,
>> LogDomains.EJB_LOGGER);
>> _logger.log(Level.SEVERE, "jacc_policy_context_exception", cause);
>>
>> 2. LogStrings.properties file entry:
>> jacc_policy_context_exception=EJB5183:JACC: Unexpected exception
>> manipulating policy context
>> EJB5183.diag.cause.1=An Exception was thrown while resetting the
>> policycontext
>> EJB5183.diag.check.1=Check the EJB policy to see if the policy
>> contexts of the application are correct
>>
>> *
>> Right now I am creating defects for following:*
>> 1. Missing message Ids in LogStrings.properties file.
>> 2. Unused message Keys from LogStrings.properties file.
>> 3. Hard-coded messages in Java file for Logging.
>>
>> I have the script for verifying logging messages. Planning to
>> integrate the same in quicklook. Let you know on this.
>>
>> If you have any question please let me know.
>>
>> Regards,
>> Naman
>
> --
> Oracle <http://www.oracle.com>
> Tom Mueller | Principal Member of Technical Staff
> Phone: +1 4029169943 | Fax: +1 4029169943 | Mobile: +1 4027206872
> 21915 Hillandale Dr | Elkhorn, NE 68022
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment