A CU found a problem in
 javax.xml.xpath.XPathFactory#newInstance(String uri)
and
javax.xml.validation.SchemaFactory#newInstance(String schemaLanguage).

Specifically, the behaviors are related to the followings in JavaSE 5 API documentation.

- javax.xml.xpath.XPathFactory#newInstance(String uri)
-----------------------------------------------
3. The class loader is asked for service provider provider-configuration files matching
javax.xml.xpath.XPathFactory in the resource directory META-INF/services.
See the JAR File Specification for file format and parsing rules. Each potential service
provider is required to implement the method:

       isObjectModelSupported(String objectModel)
     
The first service provider found in class loader order that supports the specified object
model is returned.
---------

and

- javax.xml.validation.SchemaFactory#newInstance(String schemaLanguage)
----------------------------------------------------------
3. The class loader is asked for service provider provider-configuration files matching
javax.xml.validation.SchemaFactory in the resource directory META-INF/services.
See the JAR File Specification for file format and parsing rules. Each potential service
provider is required to implement the method:

        isSchemaLanguageSupported(String schemaLanguage)
     
The first service provider found in class loader order that supports the specified schema
language is returned.
----------

The related source code portion of XPathFactory and SchemaFactory is similar.
The following explanation is based on the source code of XPathFactory
in JDK5u22 as an example.

---- javax/xml/xpath/XPathFactoryFinder#createServiceFileIterator() ----
.....
295 private Iterator createServiceFileIterator() {
296 if (classLoader == null) {
297 return new SingleIterator() {
298 protected Object value() {
299 ClassLoader classLoader = XPathFactoryFinder.class.getClassLoader();
300 return ss.getResourceAsURL(classLoader, SERVICE_ID);
301 //return (ClassLoader.getSystemResource( SERVICE_ID ));
302 }
303 };
304 } else {
305 try {
306 //final Enumeration e = classLoader.getResources(SERVICE_ID);
307 final Enumeration e = ss.getResources(classLoader, SERVICE_ID);
308 if(!e.hasMoreElements()) {
309 debugPrintln("no "+SERVICE_ID+" file was found");
310 }
311
312 // wrap it into an Iterator.
313 return new Iterator() {
314 public void remove() {
315 throw new UnsupportedOperationException();
316 }
317
318 public boolean hasNext() {
319 return e.hasMoreElements();
320 }
321
322 public Object next() {
323 return e.nextElement();
324 }
325 };
326 } catch (IOException e) {
327 debugPrintln("failed to enumerate resources "+SERVICE_ID);
328 if(debug) e.printStackTrace();
329 return new ArrayList().iterator(); // empty iterator
330 }
331 }
332 }
......
-------------------------------------------

If a context class loader(classLoader) is set, the program searches and gets a service
provider(jar file) of XPathFactory in privilege mode at the line# 307.

Then, this program accesses to the service provider(jar file) through Iterator created
at line#313.
Because this access is not done in privilege mode, if security manager does not allow to
access to the service provider(jar file), this program fails to read the service provider(jar file).

The hasNext(), next() in Iterator and hasMoreEements() at line#308 should be called in
privilege mode.
PDE is working this escaltion issue. I am adding sustaining keyword to get it off the queue. Once PDE has a fix, we will take it into revision