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?
LogManager has three chances to (re)init configuration:
1. static init
2. readConfiguration()
3. readConfiguration(InputStream)
AFAIK, there are several differences:
1. readConfiguration() and static init codes will read the
"java.util.logging.config.class" and "java.util.logging.config.file",
while readConfiguration(InputStream) won't
2. readConfiguration() and readConfiguration(InputStream) has no effect
on existing Handler instances, while static init probably doesn't, too,
but they are different because before static init codes execution,
probably no any Handler exists.
3. readConfiguration(InputStream) won't create new loggers if their
level/handlers are specified in the properties but their instances do
not exist in JVM, while static init code does, not sure how about
readConfiguration().
There may be more...
But I agree we has some other alternative to write tests, for example,
we can read and parse jre/lib/logging.properties in test codes, then
check if LogManager's behavior match the properties, which will be much
flexible and non-intrusive.
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.
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]
--
Paulex Yang
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]
