After your patch for issue #41925,
apisupport/project/test/unit/src/org/netbeans/modules/apisupport/project/ClassPathProviderImplTest.java
fails with an error when run under JDK 1.5 (b62).
I am attaching output with jaxp.debug set to true,
by creating
apisupport/project/nbproject/private/private.properties
with

test-unit-sys-prop.jaxp.debug=true

The line

j.x.p.DBF=null

indicates where DOMFactoryImpl is being
initialized and is about to call
DocumentBuilderFactory.newInstance().

Note the (repeated) lines

JAXP: find factoryId
=javax.xml.parsers.DocumentBuilderFactory
JAXP: found jar
resource=META-INF/services/javax.xml.parsers.DocumentBuilderFactory
using ClassLoader: null
JAXP: found in resource,
value=org.netbeans.core.xml.DOMFactoryImpl

What is happening? My guess:
FactoryFinder.findJarServiceProvider is finding a
context class loader which is non-null,
specifically the ext class loader. The first call
to ss.getResourceAsStream fails - there is no
provider in rt.jar (or extensions). Then cl is set
to null (FactoryFinder is in rt.jar) and ss.gRAS
is called again, this time with a null loader. Now
SecuritySupport.gRAS has this code:

if (cl == null) {
    ris = ClassLoader.getSystemResourceAsStream(name);
} else {
    ris = cl.getResourceAsStream(name);
}

Looks reasonable at first. Unfortunately
ClassLoader.gSRAS is defined as using
CL.getSystemClassLoader, which is not what we want
here - really what is wanted is
CL.getBootstrapResource, but that is private. The
problem is that CL.gSCL gives the app class
loader, which has core.jar in it (when running in
a unit test), and core.jar does have M-I/s entries
for JAXP. That means that newInstance is called
with a valid class name - o.n.c.DOMFactoryImpl -
but with a null class loader, which of course
fails since the class is not in the bootstrap loader.

IMHO this is a JDK bug and a regression from JDK
1.4 and must be filed with a minimal test case
ASAP. Probably SS.gRAS should simply return null
if cl == null, since the packagers of the JDK can
know that there are no JAXP providers in rt.jar.

In the meantime I recommend #41925 be rolled back
or implemented differently (no suggestions at the
moment, other than moving the code into an obscure
module in ide/* where it will never be used by
unit tests).

Generally, fooling around with JAXP providers is
always asking for trouble; the code is far too
complicated and deeply buggy. I was quite relieved
when we deleted the previous core-supplied JAXP
providers; a bunch of unsolvable problems
disappeared at that time (affecting unit tests,
Ant integration, etc.).