On 8/30/06, Stepan Mishura <[EMAIL PROTECTED]> 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? :-)
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? 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!).
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.
Thanks!
Thanks,
Stepan.
> Also keep in mind that the test suite is expected to be run against some
> > compatible implementation. I think nobody is going to reinstall Sun's
> JRE
> > each time after running Harmony test suite.
>
>
> Agreed. :-)
>
> --
> Andrew Zhang
> China Software Development Lab, IBM
>
>
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
