On 8/30/2012 2:20 PM, Alan Bateman 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.
Yes, it works just fine under normal conditions.
Note the old process: read the service file using TCCL (if null, system
cl), if nothing found, then BCL
Somehow I was under the impression ServiceLoader does just that so that
we could delegate to it. It's probably a good thing that it actually
doesn't. If it did, it'd cause error in the following case:
The TCCL's parent is BCL (that is Bootstrap), a jaxp impl (e.g.
Xerces) is on the classpath
Old process: try TCCL, not found, try BCL, not found
ServiceLoader: use TCCL, not found, return null (I thought it'd
continue using System CL, but it didn't)
**although worked differently, the results are the same, so not an
issue in terms of the result, still a behavior change though.
I did many tests, but so far the results are the same before and after
the patch.
If TCCL is set to null, I actually saw SCE other than SchemaFactory, for
example:
javax.xml.stream.FactoryConfigurationError:
javax.xml.stream.XMLEventFactory: Provider
org.apache.xerces.stax.XMLEventFactoryImpl not found
--Joe
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.
-Alan.
