correction below...
On Feb 7, 2007, at 9:06 AM, Geir Magnusson Jr. wrote:
>
> On Feb 7, 2007, at 7:56 AM, Tim Ellison wrote:
>
>> Geir Magnusson Jr. wrote:
>>> On Feb 7, 2007, at 7:00 AM, Tim Ellison wrote:
>>>> Rather than a hidden class loader we can filter the app
>>>> classloader's
>>>> delegation to the bootclassloader so it only gets an opportunity
>>>> to load
>>>> API types. Let me have a quick play ...
>>>
>>> Yes - that's the same concept, but I can see how that's going to be
>>> easier, because there's less machinery needed to figure out who is
>>> asking. If you don't mind, I'll take a wack.
>>
>> The hack I was thinking of is to override loadClass in
>> URLClassLoader,
>> and put a filter in there to only delegate to the parent if you
>> are the
>> system (i.e. what I would call the 'application') class loader and
>> the
>> package is one that you want to pick up.
>
> Perfect. I was looking at stuffing it into the SubURLCLassloader
> loadClass, but this is much cleaner.
>
>>
>> My first pass through only allows JSE API types, but that likely
>> won't
>> be great as it doesn't account for people putting JUnit etc. on the
>> bootclasspath and expecting it to work out. We may need to flip it
>> around and have a list of explicitly hidden packages:
>
> There are two ways I can think of :
>
> A) Have a list of system-loader verboten (mx4j, xalan, etc...)
>
> or
>
> B) Two Phase :
>
> 1) list of things on the public surface of the Java SE API :
>
> java.
> javax.
> etc
>
> so we can fail-fast for the majority of stuff and then
>
> 2) A list of things that the VM knows is allowed because they were
> placed on the bootclasspath or extension classpath by the user.
>
> and if you don't match, it's forbidden.
>
>
> I actually think that the first way is faster, since the list is
> shorter (at least right now)
>
>
>
> So the next question is for the non-static list (i.e. for option A
> or the second phase of B).
>
> This has to come from the VM, as the VM knows, and it's going to
> get messy if you want to do sophisticated things w/ the
> classloaders and such. (aka "OSGi")
>
> So...
>
> I'd like to add a new luni-kernel abstract class :
>
> o.a.h.kernel.vm.VMUtillityBase.java
>
> that has (depending on if we choose A or B) one of
>
> String[] getAppAllowedSystemLoaderList() //or something
> String[] getAppDeniedSystemLoaderList() //or something
>
> that for the Allowed version has an empty list (maybe we put JUnit
> in there...) and for the Denied version has mx4j, xalan
>
> and a class
>
> o.a.h.kernel.vm.VMUtility.java
that extends VMUtilityBase
>
> so and use VMUtility in URLClassloader to get the list. This way,
> there are no VM changes allowed now, VMs can then provide their own
"there are no VM changes *required* now"
> o.a.h.k.v.VMUtillity to reflect user-added stuff on bootclasspath
> and extentionclasspath, and in the future, we can add default
> functionality to VMUtilityBase and use it immediately w/o requiring
> changes to the VMs.
>
> Does this make any sense?
>
> geir
>
>>
>>
>> protected synchronized Class<?> loadClass(String className,
>> boolean resolveClass) throws ClassNotFoundException {
>>
>> if (this == getSystemClassLoader()) {
>> int index = className.lastIndexOf('.');
>> String pkgName = index > 0 ? className.substring(0,
>> index) : "";
>>
>> System.out.println("Checking visibility for " + pkgName);
>> if (!pkgName.startsWith("java.") && !pkgName.startsWith
>> ("javax.")
>> && !pkgName.startsWith("org.ietf.jgss")
>> && !pkgName.startsWith("org.omg")
>> && !pkgName.startsWith("org.w3c.dom")
>> && !pkgName.startsWith("org.xml.sax")) {
>> throw new ClassNotFoundException(className);
>> }
>> }
>> return super.loadClass(className, resolveClass);
>> }
>>
>
|