Too much resolution?

[starksm64]

I seem to be seeing many more of these debug msgs currently running the metadata tests:

18:07:14,709 DEBUG [JBossEntityResolver] Cannot resolve [publicID=http://www.jboss.com/xml/ns/javaee,systemID=null]
18:07:15,360 DEBUG [JBossEntityResolver] Cannot resolve [publicID=null,systemID=http://www.jboss.com/xml/ns/javaee]
18:07:15,360 DEBUG [JBossEntityResolver] Cannot resolve [publicID=http://www.jboss.com/xml/ns/javaee,systemID=null]
18:07:15,813 DEBUG [JBossEntityResolver] Cannot resolve [publicID=null,systemID=http://www.jboss.com/xml/ns/javaee]
18:07:15,814 DEBUG [JBossEntityResolver] Cannot resolve [publicID=http://www.jboss.com/xml/ns/javaee,systemID=null]
18:07:16,020 DEBUG [JBossEntityResolver] Cannot resolve [publicID=null,systemID=http://www.jboss.com/xml/ns/javaee]
18:07:16,020 DEBUG [JBossEntityResolver] Cannot resolve [publicID=http://www.jboss.com/xml/ns/javaee,systemID=null]

The majority seem to be coming from this code, triggered by elements like proxy-factory-config:

 if(resolver != null)
 {
 // this is wildcard handling
 String schemaLocation = attrs == null ? null : Util.getSchemaLocation(attrs, qName.getNamespaceURI());
 SchemaBinding schema = resolver.resolve(qName.getNamespaceURI(), null, schemaLocation);
 if(schema != null)
 {
 element = schema.getElement(qName);
 }
 }

Is there a way to improve this? Its really slowing down the tests.

[starksm64]

Its more than just the logging that is taking the time. If I reduce the logging to INFO level, parsing a standardjboss.xml descriptor is still taking > 60 seconds:

11:33:28,038 INFO [JBoss50UnitTestCase] EjbJar21Everything_testEverything.xml parse time = 1227
11:34:34,711 INFO [JBoss50UnitTestCase] JBoss5xEverything_testStandard.xml parse time = 66673
11:34:44,040 INFO [JBoss50UnitTestCase] JBoss5xEverything_testEverything.xml parse time = 9329

Seems like we need to cache the fact that a given element is a unknown wildcard to avoid the resolution thrashing going on.

[aloubyansky]

Maybe we can have a switch whether to call resolveSystemIDasURL(). I.e. resolve entities only locally: registered and in the classpath.

[aloubyansky]

The wildcard resolution doesn't seem to be the bottleneck. I tried adding the following check before the schema resolution to by-pass the resolution phase but it didn't improve the numbers.

if(!(schemaLocation == null && "".equals(qName.getNamespaceURI())))
 {
...

[starksm64]

Well, when I added the following "http://www.jboss.com/xml/ns/javaee" namespace binding to the JBoss50MetaData.class the binding time speed up 10x:

 public static SchemaBindingResolver initResolver()
 {
 DefaultSchemaResolver resolver = new DefaultSchemaResolver();
 resolver.addClassBindingForLocation("ejb-jar_2_0.dtd", EjbJar20MetaData.class);
 resolver.addClassBindingForLocation("ejb-jar_2_1.xsd", EjbJar21MetaData.class);
 resolver.addClassBindingForLocation("jboss_3_0.dtd", JBoss50DTDMetaData.class);
 resolver.addClassBindingForLocation("jboss_3_2.dtd", JBoss50DTDMetaData.class);
 resolver.addClassBindingForLocation("jboss_4_0.dtd", JBoss50DTDMetaData.class);
 resolver.addClassBindingForLocation("jboss_4_2.dtd", JBoss50DTDMetaData.class);
 resolver.addClassBindingForLocation("jboss_5_0.dtd", JBoss50DTDMetaData.class);
 resolver.addClassBindingForLocation("jboss_5_0.xsd", JBoss50MetaData.class);
 // Workaround wildard resolution slowness
 resolver.addClassBinding("http://www.jboss.com/xml/ns/javaee", JBoss50MetaData.class);
 return resolver;
 }