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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
