users@glassfish.java.net

Re: GlassFish v3 logging one pager ready for review

From: <glassfish_at_javadesktop.org>
Date: Fri, 30 Jan 2009 11:07:59 PST

Hi llc,

Thanks for all the feedback. I provided some responses below and will provide more.

. Exported interfaces: to be an interface, the fully qualified class name and exporting module must be specified for the getLogger() method cited. Also, where are logger names defined? Those too might be interfaces. Are there any other idioms that are effectively interfaces such as conventions for how logging should be structured in terms of content?

I will update the exported interfaces table. The logger names are defined and will provide that info. We do follow a format for creating the log messages as described in the Uniform Log Format Specification. I had trouble just now following the links I have to that doc.

2. We will need AMX MBeans to support configuration logging. I don't see any mention of that.
yes, I will add that.


4. Recommend shortening "in-xxx" to "xxx" eg "in-bytes" => "bytes" and "in-minutes" => "minutes".

6. Recommend renaming "log-filter" to "log-filter-classname".

7. Recommend renaming FileAndSysLogHandler to something else for V3, simply to make a fresh start and avoid confusion with V2.

I am told that anything that is already out in the public can not be changed so anything that is in the logging.properties file for Prelude will stay. Some of the names of the properties came from what is in domain.xml and I'm not sure if I can change those since those are moving. I'm trying to figure that out.


5. Recommend defining the log file property names as constants in a Java class file, also an exported interface, so that clients don't have to hard-code these constants.

Will do.

8. I don't like embedding "com.sun.enterprise.server.logging.FileandSyslogHandler" in the other properties unless you intend it to specifically apply only to that particular log handler. Is that the intent? Can a different log handler be used, and if so, what happens to these properties, do they apply somehow?
It is a particular handler that we supply by default and that can be replaced at runtime. The properties are used by this handler. Anyone can write a custom handler and use the properties if they like but in general if someone wants to replace the default handler we supply the properties would not apply.

9. I think Uncommitted stability for logging.properties is problematic. This is a very important interface.
I think I'm just unfamiliar with the values here. I thought that uncommitted meant that we are still working on it and it is not final. Once the one pager has been reviewed that value would change.
[Message sent by forum member 'carlavmott' (carlavmott)]

http://forums.java.net/jive/thread.jspa?messageID=329291