harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Date Tue, 05 Sep 2006 07:03:49 GMT
On 9/5/06, Paulex Yang wrote:
>
> Stepan Mishura wrote:
> > On 9/4/06, *Paulex Yang* wrote:
> >
> >     Stepan Mishura wrote:
> >     > On 9/1/06, Paulex Yang wrote:
> >     >>
> >     >> Stepan Mishura wrote:
> >     >> > Hi Andrew,
> >     >> >
> >     >> > I've just looked into static initialization block and then to
> the
> >     >> > spec. for
> >     >> > LogManager class.
> >     >> > My impression is that Harmony implementation doesn't follow
> >     the spec.
> >     >> >
> >     >> > The spec. says: "At startup the LogManager class is located
> using
> >     >> the '
> >     >> > java.util.logging.manager' system property.By default, the
> >     LogManager
> >     >> > reads
> >     >> > its initial configuration from a properties file
> >     >> > "lib/logging.properties" in
> >     >> > the JRE directory...."
> >     >> Stepan,
> >     >>
> >     >> I think the meaning of "By default" is debatable. Actually the
> >     spec
> >     >> looks like this:
> >     >>
> >     >> "At startup the LogManager class is located using the
> >     >> java.util.logging.manager system property.
> >     >>
> >     >> By default, the LogManager reads its initial configuration from a
> >     >> properties file "lib/logging.properties" in the JRE directory.
> >     If you
> >     >> edit that property file you can change the default logging
> >     configuration
> >     >> for all uses of that JRE.
> >     >>
> >     >> In addition, the LogManager uses two optional system properties
> >     that
> >     >> allow more control over reading the initial configuration:
> >     >>
> >     >>    * "java.util.logging.config.class"
> >     >>    * "java.util.logging.config.file"...
> >     >>
> >     >> "
> >     >>
> >     >> So I consider the "By default" doesn't necessarily means
> >     default case
> >     >> without " java.util.logging.manager" property, but means the
> >     default case
> >     >> without "java.util.logging.config.class/file" properties.
> >     >>
> >     >> A simple test on RI of specifying a customized MockLogManager by
> >     >> "j.u.l.manager" property shows the default
> >     "lib/logging.properties" does
> >     >> affect the behavior of the customized LogManager, say the root
> >     logger's
> >     >> level, etc.
> >     >
> >     >
> >     > Do you mean that RI resets the root logger's level of customized
> >     > LogManager
> >     > to default value from "lib/logging.properties"?
> >     Yes, so I think customized LogManager also needs to initialize
> >     itself in
> >     same procedure as j.u.l.LogManager.
> >
> >
> >
> > Hi Paulex,
> >
> > I've implemented custom LogManager (see attachment): it sets value for
> > root logger's level different from default value(INFO). According to
> > my test (see attachment) RI doesn't change level of root logger.
> >
> > The test prints the following:
> > $java -classpath . MyTest
> > INFO
> > $java -classpath . -Djava.util.logging.manager=CustomLogManager MyTest
> > SEVERE
> >
> > Did I missed something?
> Stepan,
>
> I run the test under Sun JDK 1.5.0_06 for WinXP, but I got "INFO"
> printed for both cases...



Hmm, interesting. I've tried with BEA JRE ... going to check with Sun's

Thanks,
Stepan Mishura
Intel Middleware Products Division

------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message