classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: SecurityManager troubles


From: Jeroen Frijters
Subject: RE: SecurityManager troubles
Date: Fri, 13 Jan 2006 07:55:22 +0100

I forgot to attach the patch. 

Regards,
Jeroen

> -----Original Message-----
> From: Jeroen Frijters 
> Sent: Friday, January 13, 2006 07:54
> To: 'Archie Cobbs'; Gary Benson
> Cc: Classpath List
> Subject: RE: SecurityManager troubles
> 
> Archie Cobbs wrote:
> > Gary Benson wrote:
> > > Isn't the boot class loader solely for java.lang?
> > 
> > No.. under the Java2 delegation model, the boot class loader
> > should be given the first chance to try and load *every* class.
> > 
> > Typically it will only find classes in glibj.zip (or rt.jar,
> > or whatever your VM equivalent of the core library is) because
> > that's all it knows to look in. So then the child classloader(s)
> > get to try.
> > 
> > In any case I'm still not clear on this problem. Yesterday it
> > looked to me like a result of delayed method resolution by kaffe.
> > But that could be completely off. I haven't actually witnessed
> > the problem so can't really say for sure without additional info.
> > 
> > It would be nice however to get to the bottom of it before 0.20...
> 
> I think I figured it out. With the attached test I could 
> reproduce the problem on IKVM as well. The attach Classpath 
> patch fixing things, although past 0.20 I think we should 
> refactor the security properties like I did with the system 
> properties (i.e. introduce a gnu.classpath.SecurityProperties class).
> 
> As you can see in the test, there is still the incorrect 
> "charsetProvider" permission being checked. I'm looking into 
> that one as well.
> 
> Regards,
> Jeroen
> 

Attachment: secman.patch.txt
Description: secman.patch.txt


reply via email to

[Prev in Thread] Current Thread [Next in Thread]