xml commons resolver

[queshaw]

This is either a feature request, or a question about how I should solve a problem.

I use custom catalog entries with xml commons resolver (i.e. I extend Catalog and OASISXmlCatalogReader), but oxygen seems to use it's own version of classes with the same name as classes in xml commons resolver, in oxygen.jar, so my URI resolver was failing at runtime. Specifically, there is no Catalog.catalogEntries field in org.apache.xml.resolver.Catalog that is in oxygen.jar.

I am using a class loader to get around the problem, by explicitly loading classes from resolver.jar instead. But, unless I should be solving this a different way, it would be convenient if oxygen did not include classes below the package org.apache.xml.resolver that are different from the classes in xml commons resolver.

[adrian]

Hi,

Oxygen does indeed patch org.apache.xml.resolver.Catalog for a few fixes and optimizations. But Catalog.catalogEntries is still there, it's of a different type but it extends a Vector(the original type):

Code: Select all

protected AccessibleVector catalogEntries = new AccessibleVector();

private static class AccessibleVector extends Vector{

  public Object[] getElementData(){

    return elementData;

  }

}

So it's nothing sensibly different, you should be able to access it just the same as the original:

Code: Select all

protected Vector catalogEntries = new Vector();

The class loader is the way to go if you absolutely need the original Catalog but I think it should have worked with Oxygen's as well.

Regards,
Adrian

[queshaw]

Thank you. I was getting a java.lang.NoSuchFieldError. And, if I compiled with oxygen.jar I would get an error about AccessibleVector not being visible. But, as you've said, I can cast catalogEntries to Vector, and I no longer need the class loader.

Would you consider putting your patched classes into a jar separate from oxygen.jar?

[adrian]

Hi,

We will consider putting the patches in a separate jar.
Some of these patches are critical to the Oxygen functionality so that's why they are built-in.

Regards,
Adrian