RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

[Paul Sandoz]

On Aug 30, 2012, at 11:20 PM, Alan Bateman <Alan.Bateman at 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.