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 Wed, 30 Aug 2006 09:40:57 GMT
On 8/30/06, Andrew Zhang wrote:
>
> On 8/30/06, Stepan Mishura wrote:
> >
> > On 8/30/06, Andrew Zhang wrote:
> >
> > > On 8/30/06, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I was browsing thought logging tests and realized that running
> logging
> > > > test
> > > > suite cause updates of tested JRE configuration.
> > > > The ant script changes jre/lib/logging.properties file by:
> > > >
> > > >    <target name="copy.resources">
> > > >        <copy todir="${hy.jdk}/jre/lib" overwrite="yes"
> flatten="yes">
> > > >            <fileset dir="${hy.logging.src.main.java}">
> > > >                <include name="**/logging.properties" />
> > > >            </fileset>
> > > >        </copy>
> > > >    </target>
> > > >
> > > > I do believe that we shouldn't do testing in this way - if a test
> > > requires
> > > > special env. configuration(different from JRE's default) the test
> > suite
> > > > shouldn't *hack* JRE config files. We should consider dynamic env.
> > > > reconfiguration. For example, for this particular case is there any
> > > > problem
> > > > with using LogManager.readConfiguration(InputStream) to reinitialize
> > the
> > > > logging properties?
> > >
> > >
> > > Yes, they're different. :-) Static first initialization acts
> differently
> > > from readConfiguration if you take a look at the source code. :)
> >
> >
> > Could you describe in few words what is the difference?
>
>
> The static initialization block looks different from readConfigure(),
> doesn't it? :-)


OK. I'll look into.

Let the test authors speak for themselves. However, I think specifying
> test.properties makes sense sometimes. Consider following test scenario:
>
> "java.util.logging.config.class" is set. We want to verify that LogManager
> is loaded as "java.util.logging.config.class" property, rather than
> "lib/logging.properties" in the JRE directory. How could we assert the
> result?


A test can fork VM with -Djava.util.logging.config.class=<some class> and
verify that required class was used.

 We should assert the loaded handlers, level, ... are the same as "
> java.util.logging.config.class", and properties in
> "lib/logging.properties"
> are not loaded.  Notice that the default lib/logging.properties may
> be changed by users. It's better to use a certain test properties than
> uncertain default properties(we can't assume users never try to modify
> it!).


It is up to user to set JRE default properties and the testing suite
shouldn't modify them because there is a risk to damage user's default
settings.

But after looking at the test cases, it seems there are no such tests. May
> such tests are deleted? I noticed serveral variables are not used, like
> CONFIG_CLASS, CONFIG_FILE, and etc...
>
>
> > But I do agree that we should not change jre config in this way!  I
> > > suggest
> > > solve this problem in following way:
> > > 1. backup jre default logging.properties in ant before running logging
> > > test.
> > >
> > > 2. copy test logging.properties to jre before running logging test.
> > > 3. restore jre config when logging test ends.
> > >
> > > Make senses?
> >
> >
> > I'd prefer not touch JRE files at all. For example, what if the suite
> run
> > is interrupted in the middle? I'm not quite comfort if Harmony test
> suite
> > touches RI's config files on my local disk.
>
>
> Basically, I agree with you. But it doesn't happen without any cost. We
> can't write some tough tests like the example mentioned above. If we
> decide
> to delete these overkilled tests(seems I can't find such test in logging
> module :) ), I totally agree that never touch jre config file. Otherwise,
> it's acceptable to me that ant test tries its best to restore the default
> properties file, and ant build always puts the default
> logging.propertiesfile to deploy directory.


What about specifying "java.util.logging.config.file" property in the ant
script?

<jvmarg value="-java.util.logging.config.file=<Harmony testing properties
file>"/>

IMO it solves the issue

Thanks,
Stepan.

------------------------------------------------------
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