The thing that resolves schemas is JBossEntityResolver. http://anonsvn.jboss.org/repos/common/common-core/trunk/src/main/java/org/jboss/util/xml/JBossEntityResolver.java
For details you can check its resolveEntity method.

You can specify schemaLocation in XML. Or make it available in the classpath.

As to the META-INF, seems like a good idea, but to get to resources there using thread classloader I think you'd have to prefix the resource name with 'META-INF/'? Which JBossEntityResolver doesn't do. It tries the resource name as is first and if that failed then with prefixes 'dtd/' and 'schema/'.

https://jira.jboss.org/jira/browse/JBXB-195 outlines a similar problem with prototype solution attached.

Basically the knowledge in SingletonSchemaResolverFactory's constructor should not be there. It's dependent on internals of the artifacts provided by consuming components.

I wouldn't say it's a similar issue.
It depends on what you want to do but SingletonSchemaResolverFactory may not be a good choice for this feature. It's singleton, so it's one for all. While, theoretically, different JARs may use different classes for the same namespace. In this case, component-specific configuration shouldn't modify global configuration. Instead, there should be a JAR-specific SchemaBindingResolver which would delegate to the SingletonSchemaResolverFactory (or whatever the global resolver is) in case it can't resolve the binding by itself.
If bindings from different JARs don't and can't contradict each other then no problem.