You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stepan Mishura <st...@gmail.com> on 2006/08/30 07:03:26 UTC
[classlib][logging] a test suite shouldn't touch any of JRE config files!!!
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?
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.
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
On 8/31/06, Stepan Mishura wrote:
> On 8/31/06, Stepan Mishura wrote:
>
> > On 8/30/06, Mark Hindess wrote:
> > >
> > >
> > On 30 August 2006 at 12:03, "Stepan Mishura"
> > 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>
> >
> > The 'test' target depends on 'build' which in turn depends on the above
> > 'copy.resources' target. So this seems perfectly reasonable to me.
> >
> >
> > Hmm, but the file is changed during test suite run and even not
> > restored. I'll look into...
> >
> >
>
> Aha, test support class[1] changes the file.
>
> Thanks,
> Stepan.
>
> [1]http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/logging/src/test/java/org/apache/harmony/logging/tests/java/util/logging/util/DefaultPropertyHelper.java?view=markup
>
>
>
Any volunteer to fix that?
-Stepan.
> It's copying it to the jre to make the jre complete. It is part of the
> > > build not the test process.
> > >
> > > If it was copying to test.jre.home I'd be worried but I don't really
> > > see
> > > why this should be a problem.
> > >
> > > Regards,
> > > Mark.
> > >
> > > > 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?
> > > > 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.
> > > >
> > > >
> > >
> >
------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
On 8/31/06, Stepan Mishura wrote:
> On 8/30/06, Mark Hindess wrote:
> >
> >
> On 30 August 2006 at 12:03, "Stepan Mishura"
> 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>
>
> The 'test' target depends on 'build' which in turn depends on the above
> 'copy.resources' target. So this seems perfectly reasonable to me.
>
>
> Hmm, but the file is changed during test suite run and even not restored.
> I'll look into...
>
>
Aha, test support class[1] changes the file.
Thanks,
Stepan.
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/logging/src/test/java/org/apache/harmony/logging/tests/java/util/logging/util/DefaultPropertyHelper.java?view=markup
> Thanks,
> Stepan.
>
> It's copying it to the jre to make the jre complete. It is part of the
> > build not the test process.
> >
> > If it was copying to test.jre.home I'd be worried but I don't really see
> > why this should be a problem.
> >
> > Regards,
> > Mark.
> >
> > > 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?
> > > 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.
> > >
> > >
> >
>
>
------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
On 8/30/06, Mark Hindess wrote:
>
>
> On 30 August 2006 at 12:03, "Stepan Mishura"
> 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>
>
> The 'test' target depends on 'build' which in turn depends on the above
> 'copy.resources' target. So this seems perfectly reasonable to me.
Hmm, but the file is changed during test suite run and even not restored.
I'll look into...
Thanks,
Stepan.
It's copying it to the jre to make the jre complete. It is part of the
> build not the test process.
>
> If it was copying to test.jre.home I'd be worried but I don't really see
> why this should be a problem.
>
> Regards,
> Mark.
>
> > 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?
> > 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.
> >
> >
>
------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Mark Hindess <ma...@googlemail.com>.
On 30 August 2006 at 12:03, "Stepan Mishura" <st...@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>
The 'test' target depends on 'build' which in turn depends on the above
'copy.resources' target. So this seems perfectly reasonable to me.
It's copying it to the jre to make the jre complete. It is part of the
build not the test process.
If it was copying to test.jre.home I'd be worried but I don't really see
why this should be a problem.
Regards,
Mark.
> 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?
> 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.
>
> 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
>
> ------=_Part_17401_4283173.1156914206767--
---------------------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config
files!!!
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
+1
Stepan Mishura 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?
> 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.
>
> 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
>
---------------------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config
files!!!
Posted by Paulex Yang <pa...@gmail.com>.
Stepan Mishura wrote:
> On 8/30/06, Andrew Zhang wrote:
>
>> On 8/30/06, Stepan Mishura <st...@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?
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
On 9/1/06, Andrew Zhang wrote:
>
> On 8/31/06, Mikhail Loenko wrote:
> > 2006/8/30, Stepan Mishura :
> > > On 8/30/06, Andrew Zhang wrote:
> > >
> > > > On 8/30/06, Stepan Mishura <st...@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?
> > >
> > >
> > >
> > > > 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.
> >
> > +1
> >
> > I'm also not quite comfort if Harmony testsuite touches any files on my
> > disk
> > out of the sandbox where the project sits.
> >
> > also I'd not be happy if it formats my disks or sends messages from my
> > account.
>
>
> If Harmony would potientially format my disk, I'll remove it from my disk
> right away. :)
Don't hurry! We may provide a test suite with three pop-up windows that
appears one after another:-)
1) These tests may format your disk. Proceed? (Yes/No)
2) Are you sure that you want to run tests tests anyway? (Yes/No)
3) This is your last chance! Cancel? (Yes/No)
Thanks,
Stepan.
Thanks,
> > Mikhail
> >
> > >
> > > 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Andrew Zhang <zh...@gmail.com>.
On 8/31/06, Mikhail Loenko <ml...@gmail.com> wrote:
>
> 2006/8/30, Stepan Mishura <st...@gmail.com>:
> > On 8/30/06, Andrew Zhang wrote:
> >
> > > On 8/30/06, Stepan Mishura <st...@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?
> >
> >
> >
> > > 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.
>
> +1
>
> I'm also not quite comfort if Harmony testsuite touches any files on my
> disk
> out of the sandbox where the project sits.
>
> also I'd not be happy if it formats my disks or sends messages from my
> account.
If Harmony would potientially format my disk, I'll remove it from my disk
right away. :)
Thanks,
> Mikhail
>
> >
> > 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: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/8/30, Stepan Mishura <st...@gmail.com>:
> On 8/30/06, Andrew Zhang wrote:
>
> > On 8/30/06, Stepan Mishura <st...@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?
>
>
>
> > 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.
+1
I'm also not quite comfort if Harmony testsuite touches any files on my disk
out of the sandbox where the project sits.
also I'd not be happy if it formats my disks or sends messages from my account.
Thanks,
Mikhail
>
> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
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 <st...@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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
On 9/5/06, Paulex Yang wrote:
>
> Stepan Mishura wrote:
> > Paulex, thanks for your patience and answers.
> >
> > Yes, Sun's JRE sets root logger's level according to
> > 'lib/logging.properties'. Also specifying the level for root logger in
> > j.u.l.config.file doesn't help. (I assumed before that a JRE respects my
> > "lovely" custom LogManager settings :-(! )
> >
> > OK. Let's return to the initial issue: how to run logging tests without
> > changing JRE config files?
> >
> > I still believe that there should be some elegant way for testing
> logging
> > implementation without touching JRE files.
> I agreed this is not acceptable. AFAIK current LogManagerTest has used a
> MockLogManager in most test cases, so the migration should be relatively
> easy.
> > For example, what
> > about developing custom LogManager for testing? The testing manager will
> > work in 2 modes: default configuration and custom configuration. A
> > test will
> > have a hook to switch testing manager's mode. The first configuration is
> > read from JRE config files (by j.u.l.LogManager implementation) and the
> > second one will be fully controlled by a test and is set by the test
> > via some manager's method (say readConfiguration(InputStream)). Does
> this
> > sound crazy?
> Maybe we just need one Support_Exec() invocation to verify if the
> LogManager reads the default logging
> properties(jre/lib/logging.properties) correctly(which should be
> straightforward by also loading and parsing that properties in test
> codes), for other tests, we always use customized LogManager or
> configuration files. If you are fine with this, I'm volunteer to
> refactor the tests.
>
> Agree with this approach.
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config
files!!!
Posted by Paulex Yang <pa...@gmail.com>.
Stepan Mishura wrote:
> Paulex, thanks for your patience and answers.
>
> Yes, Sun's JRE sets root logger's level according to
> 'lib/logging.properties'. Also specifying the level for root logger in
> j.u.l.config.file doesn't help. (I assumed before that a JRE respects my
> "lovely" custom LogManager settings :-(! )
>
> OK. Let's return to the initial issue: how to run logging tests without
> changing JRE config files?
>
> I still believe that there should be some elegant way for testing logging
> implementation without touching JRE files.
I agreed this is not acceptable. AFAIK current LogManagerTest has used a
MockLogManager in most test cases, so the migration should be relatively
easy.
> For example, what
> about developing custom LogManager for testing? The testing manager will
> work in 2 modes: default configuration and custom configuration. A
> test will
> have a hook to switch testing manager's mode. The first configuration is
> read from JRE config files (by j.u.l.LogManager implementation) and the
> second one will be fully controlled by a test and is set by the test
> via some manager's method (say readConfiguration(InputStream)). Does this
> sound crazy?
Maybe we just need one Support_Exec() invocation to verify if the
LogManager reads the default logging
properties(jre/lib/logging.properties) correctly(which should be
straightforward by also loading and parsing that properties in test
codes), for other tests, we always use customized LogManager or
configuration files. If you are fine with this, I'm volunteer to
refactor the tests.
>
> Thoughts? Other suggestions?
>
> 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
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
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...
Paulex, thanks for your patience and answers.
Yes, Sun's JRE sets root logger's level according to
'lib/logging.properties'. Also specifying the level for root logger in
j.u.l.config.file doesn't help. (I assumed before that a JRE respects my
"lovely" custom LogManager settings :-(! )
OK. Let's return to the initial issue: how to run logging tests without
changing JRE config files?
I still believe that there should be some elegant way for testing logging
implementation without touching JRE files. For example, what
about developing custom LogManager for testing? The testing manager will
work in 2 modes: default configuration and custom configuration. A test will
have a hook to switch testing manager's mode. The first configuration is
read from JRE config files (by j.u.l.LogManager implementation) and the
second one will be fully controlled by a test and is set by the test
via some manager's method (say readConfiguration(InputStream)). Does this
sound crazy?
Thoughts? Other suggestions?
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config
files!!!
Posted by Paulex Yang <pa...@gmail.com>.
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...
>
> Thanks,
> Stepan.
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
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?
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config
files!!!
Posted by Paulex Yang <pa...@gmail.com>.
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.
>
> Thanks,
> Stepan.
>
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
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"?
Thanks,
Stepan.
>
> > So if the property 'java.util.logging.manager' is not set a default
> > implementation is used. The default implementation looks for '
> > java.util.logging.config.class' and 'java.util.logging.config.file'
> > system
> > properties, reads config from 'jre/lib/logging.properties' and so on.
> > If the mentioned property is set then a custom LogManager class
> > implementation is used. And it is up to the custom implementation how to
> > load configuration. Right?
> >
> > But Harmony implementation follows default initialization procedure in
> > any
> > case. It loads the custom LogManager, looks for '
> > java.util.logging.config.class' and 'java.util.logging.config.file'
> > system
> > properties and if none of them are set and it forces the custom
> > LogManager to read properties from 'jre/lib/logging.properties' file.
> > Why?
> > It is up to the custom implementation whether to read it or not.
> > Did I missed something?
> >
> > Thanks,
> > Stepan.
> >
> >
> > <SNIP>
> >
>
> ------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config
files!!!
Posted by Paulex Yang <pa...@gmail.com>.
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.
>
> So if the property 'java.util.logging.manager' is not set a default
> implementation is used. The default implementation looks for '
> java.util.logging.config.class' and 'java.util.logging.config.file'
> system
> properties, reads config from 'jre/lib/logging.properties' and so on.
> If the mentioned property is set then a custom LogManager class
> implementation is used. And it is up to the custom implementation how to
> load configuration. Right?
>
> But Harmony implementation follows default initialization procedure in
> any
> case. It loads the custom LogManager, looks for '
> java.util.logging.config.class' and 'java.util.logging.config.file'
> system
> properties and if none of them are set and it forces the custom
> LogManager to read properties from 'jre/lib/logging.properties' file.
> Why?
> It is up to the custom implementation whether to read it or not.
> Did I missed something?
>
> Thanks,
> Stepan.
>
>
> <SNIP>
>
>
> ------------------------------------------------------
> 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
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
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 <st...@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? :-)
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...."
So if the property 'java.util.logging.manager' is not set a default
implementation is used. The default implementation looks for '
java.util.logging.config.class' and 'java.util.logging.config.file' system
properties, reads config from 'jre/lib/logging.properties' and so on.
If the mentioned property is set then a custom LogManager class
implementation is used. And it is up to the custom implementation how to
load configuration. Right?
But Harmony implementation follows default initialization procedure in any
case. It loads the custom LogManager, looks for '
java.util.logging.config.class' and 'java.util.logging.config.file' system
properties and if none of them are set and it forces the custom
LogManager to read properties from 'jre/lib/logging.properties' file. Why?
It is up to the custom implementation whether to read it or not.
Did I missed something?
Thanks,
Stepan.
<SNIP>
------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Andrew Zhang <zh...@gmail.com>.
On 8/30/06, Stepan Mishura <st...@gmail.com> wrote:
>
> On 8/30/06, Andrew Zhang wrote:
>
> > On 8/30/06, Stepan Mishura <st...@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? :-)
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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Stepan Mishura <st...@gmail.com>.
On 8/30/06, Andrew Zhang wrote:
> On 8/30/06, Stepan Mishura <st...@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?
> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][logging] a test suite shouldn't touch any of JRE config
files!!!
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Andrew Zhang wrote:
> Yes, they're different. :-) Static first initialization acts differently
> from readConfiguration if you take a look at the source code. :)
> 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.
What if the test fails, leaving things in a broken state?
geir
---------------------------------------------------------------------
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
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Posted by Andrew Zhang <zh...@gmail.com>.
On 8/30/06, Stepan Mishura <st...@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. :)
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?
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. :-)
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
>
>
--
Andrew Zhang
China Software Development Lab, IBM