harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [classlib][logging] A non bug difference from RI?
Date Wed, 30 Aug 2006 08:28:33 GMT
Stepan Mishura wrote:
> On 8/30/06, Andrew Zhang wrote:
>>
>> On 8/30/06, Stepan Mishura wrote:
>> >
>> > On 8/30/06, Andrew Zhang wrote:
>> > >
>> > > Hi folks,
>> > >
>> > > When SecurityManager is enabled and all file permissions are 
>> disabled,
>> > RI
>> > > fails to new a FileHandler while Harmony allows.
>> > > Following test code shows the differences:
>> > >
>> > >    public void test_FileHandler() throws Exception {
>> > >        FileHandler handler = new FileHandler();
>> > >        SecurityManager originalSecurityManager =
>> > System.getSecurityManager
>> > > ();
>> > >        try {
>> > >            System.setSecurityManager(new MockFileSecurityManager());
>> > >            handler.publish(new LogRecord(Level.SEVERE, "msg"));
>> > >
>> > > // SecurityException is thrown here
>> > >            handler.close();
>> > >        } finally {
>> > >            System.setSecurityManager(originalSecurityManager);
>> > >        }
>> > >    }
>> > >
>> > >    public static class MockFileSecurityManager extends 
>> SecurityManager
>> {
>> > >        public void checkPermission(Permission perm) {
>> > >            if (perm instanceof FilePermission) {
>> > >                System.out.println("check " + perm.getName());
>> > >                throw new SecurityException();
>> > >            }
>> > >        }
>> > >    }
>> > > FileHandler.close() spec says "Throws: SecurityException - if a
>> security
>> > > manager exists and if the caller does not have
>> > > LoggingPermission("control").", In the code above, control 
>> permission
>> is
>> > > allowed. The failure stack trace against RI looks like:
>> > >
>> > > java.lang.SecurityException
>> > > at com.andrew.LoggingTest$MockFileSecurityManager.checkPermission(
>> > > LoggingTest.java:131)
>> > > at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
>> > > at java.io.File.exists(File.java:700)
>> > > at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:401)
>> > > at java.io.File.getCanonicalPath(File.java:531)
>> > > at java.io.FilePermission$1.run(FilePermission.java:218)
>> > > at java.security.AccessController.doPrivileged(Native Method)
>> > > at java.io.FilePermission.init(FilePermission.java:212)
>> > > at java.io.FilePermission.<init>(FilePermission.java:264)
>> > > at java.lang.SecurityManager.checkDelete(SecurityManager.java:990)
>> > > at java.io.File.delete(File.java:869)
>> > > at java.util.logging.FileHandler.close(FileHandler.java:594)
>> > > at com.andrew.LoggingTest.test_FileHandler(LoggingTest.java:121)
>> > > ...
>> > >
>> > > The output is "check C:\Documents and
>> Settings\myaccount\java0.log.lck"
>> > >
>> > > It seems RI tries to delete <log file>.lck file, but has no
>> permission.
>> > > ".lck" file is never mentioned in spec, and should be implementation
>> > > detail.
>> > >
>> > > Current Harmony code never tries to lock a temp empty .lck file, so
>> the
>> > > test
>> > > passes against Harmony.
>> >
>> >
>> > If I understoond correctly, new FileHandler() creates temporary 
>> file for
>> > logging (its name is defined by default configuration properties). 
>> That
>> is
>> > true for Harmony and RI. Right?
>>
>>
>> Stepan, you missed something here. :)
>> Both Harmony and RI creates a file (not temporary) for logging, and RI
>> created one more file(temporary) for locking.
>> RI tries to delete the temporary .lck file when fileHandler.close() is
>> invoked. Harmony has nothing to be deleted. :)
>
>
> IOW, Harmony uses different locking approach for log-files and the test
> above demonstrate side-effect of different approaches. Right?
IMO, this test show RI's locking mechanism has side-effect(needs more 
file permissions), while Harmony's is more clean.
>
> IMO, we should add a note to the documentation: why we chose different
> locking approach.
Agree, documentation is useful here. Actually I'm a little confused why 
RI chose its current locking approach, IIRC, why the file needs to be 
locked is due to the spec[1], and IMO the spec hints the lock of logging 
file needs to be detected and held.

[1] "However, if the FileHandler tries to open the filename and finds 
the file is currently in use by another process it will increment the 
unique number field and try again."
>
> Thanks,
> Stepan.
>
>> RI tries to delete the created file if FileHandler.close() is 
>> invoked. And
>> > Harmony doesn't. Why?
>> >
>> > Thanks,
>> > Stepan.
>> >
>> > If we revise the MockSecurityManager a little, to allow .lck file
>> > > permission,
>> > >
>> > >    public void checkPermission(Permission perm) {
>> > >            if (perm instanceof FilePermission) {
>> > >                if (perm.getName().indexOf(".lck") == -1) {
>> > >                    System.out.println("check " + perm.getName());
>> > >                    throw new SecurityException();
>> > >                }
>> > >            }
>> > >        }
>> > >
>> > > The test will pass both against RI and Harmony.
>> > >
>> > > So I'd suggest to leave it as "non-bug difference from RI".
>> > >
>> > > Any comments? Thank you!
>> > >
>> > >
>> > >
>> > > --
>> > > 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


Mime
View raw message