On Aug 30, 2012, at 11:20 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
> On 30/08/2012 19:38, Joe Wang wrote:
>> Hi Paul, Alan,
>>
>> I've read your latest comments. Before getting back to you on those items,
>> I felt it's important we get the classloader handling correctly. If it's as
>> what I suspected (as I described in the last email), we may have problem
>> with using ServiceLoader.
>>
>> I've read Paul's explanation, esp. the delegation to
>> ClassLoader.getSystemResourceAsStream part. It looks right as it's stated
>> in the spec. But I do remember it was the issue for CR6723276 and I did
>> change it to Object.class.getResourceAsStream (without a way to call
>> bootstrap classloader).
>>
>> Just as Paul said, the classloader stuff is quite tricky. I had three dummy
>> jars that I've been running tests with. I haven't had problems loading
>> those jars. But the tests were under 'normal' conditions, that is, the
>> usual jdk classloader hierarchy was followed.
>>
>> Also, dummy jars may work. But I should at least test Xerces. So that's what
>> I'm going to do as well.
>>
>> --Joe
> I don't think I'm following the concern here as I thought the SecuritySupport
> will either give you the TCCL or the system class loader (but never null). As
> I quick check I created a no-op SchemaFactory, packaged it up with
> META-INF/services/javax.xml.validation.SchemaFactory into a JAR and verified
> that it was located when I deploy it on either the class path or extensions
> directory. In this case, the thread invoking SchemaFactory.newInstance had
> its TCCL set to the system class loader (the default). Same thing if I change
> the TCCL to null because SecuritySupport gives the Finder the system class
> loader for that case.
>
It seems the SecuritySupport variants have slightly different functionality.
javax.xml.stream.SecuritySupport:
ClassLoader getContextClassLoader() throws SecurityException{
return (ClassLoader)
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
ClassLoader cl = null;
//try {
cl = Thread.currentThread().getContextClassLoader();
//} catch (SecurityException ex) { }
if (cl == null)
cl = ClassLoader.getSystemClassLoader();
return cl;
}
});
}
javax.xml.datatype.SecuritySupport:
ClassLoader getContextClassLoader() {
return (ClassLoader)
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
ClassLoader cl = null;
try {
cl = Thread.currentThread().getContextClassLoader();
} catch (SecurityException ex) { }
return cl;
}
});
}
I made an incorrect assumption that javax.xml.datatype.SecuritySupport was the
same as all the others.
> Paul - slap me in the face if I have this wrong, I don't want to cause any
> confusion on this, I really just want to see a current vs. proposed behavior
> for each of the finders.
>
I am getting bogged down in the weeds on this. This area is more inconsistent
than i previously thought. I think we need tests and enumerate exactly the
loading policy for each factory finder.
Paul.
