Re: [docbook-apps] XPointer resolution

I am running the command line as an external process.

I solved it by adding saxon.jar from the oXygen installation directory to the classpath as you suggested,and in addition rearranging all the jar files in the classpath to the following:

* dir containing CatalogManager.properties, resolver.jar, CatalogManager.properties

* log4j.jar, oxygen.jar, xercesImpl.jar (from oXygen)

* saxon-xml-apis.jar, xt.jar, crimson.jar (from XEP)

* saxon65.jar (from DocBook extensions)

* saxon.jar (from oXygen)

Thanks for guiding me to a solution! :)

Bergfrid Skaara

On Wed, May 7, 2014 at 3:26 PM, Radu Coravu <> wrote:

Hi Bergfrid,

I'm not sure what the problem is, are you running the command line as an external process or from an ANT build file?

You could try to add the oxygen.jar as the first entry in the classpath (we also have some Saxon 6 patches) and use the "saxon.jar" from the Oxygen installation folder.

Regards,

Radu

Radu Coravu

<oXygen/>  XML Editor, Schema Editor and XSLT Editor/Debugger

http://www.oxygenxml.com

On 5/7/2014 3:39 PM, Bergfrid Skaara wrote:

Here is the stack trace:

Exception in thread "main" java.lang.NoSuchFieldError: catalogEntries

         at org.apache.xml.resolver.Resolver.resolveURI(Resolver.java:163)

         at

org.apache.xml.resolver.Catalog.resolveSubordinateCatalogs(Unknown Source)

         at org.apache.xml.resolver.Catalog.resolveURI(Unknown Source)

         at org.apache.xml.resolver.Resolver.resolveURI(Resolver.java:158)

         at

org.apache.xml.resolver.Catalog.resolveSubordinateCatalogs(Unknown Source)

         at org.apache.xml.resolver.Catalog.resolveURI(Unknown Source)

         at org.apache.xml.resolver.Resolver.resolveURI(Resolver.java:158)

         at

org.apache.xml.resolver.Catalog.resolveSubordinateCatalogs(Unknown Source)

         at org.apache.xml.resolver.Catalog.resolveURI(Unknown Source)

         at org.apache.xml.resolver.Resolver.resolveURI(Resolver.java:158)

         at

org.apache.xml.resolver.tools.CatalogResolverXerces.resolve(Unknown Source)

         at com.icl.saxon.StyleSheet.doMain(StyleSheet.java:250)

         at com.icl.saxon.StyleSheet.main(StyleSheet.java:47)

This was triggered by adding oxygen.jar and log4j.jar to the classpath.

The java saxon/xerces command is unchanged.

On Wed, May 7, 2014 at 2:30 PM, Radu Coravu <

<mailto:>> wrote:

    Hi Bergfrid,

    Please try to post the entire stack trace of the received

    NoSuchFieldError.

    Regards,

    Radu

    Radu Coravu

    <oXygen/>  XML Editor, Schema Editor and XSLT Editor/Debugger

    http://www.oxygenxml.com

    On 5/7/2014 2:45 PM, Bergfrid Skaara wrote:

        Yes to all of the above, you got my setup correct.

        I already had xercesImpl.jar from the "OXYGEN_INSTALL_DIR" in my

        classpath. When I added oxygen.jar before it, it complained about

        missing log4j, so I added that jar as well. Now it complains about

        NoSuchFieldError: catalogEntrries

        The command did resolve catalogs just finge before I added

        oxygen.jar

        Are there any other dependencies for oxygen.jar that I should

        add, or

        internal order that I need to tweak?

        I have the following in my classpath, in the order given:

        * saxon.jar (from XEP)

        * saxon65.jar (from docbook distribution extension dir)

        * log4.jar (from oxygen)

        * oxygen.jar

        * xercesImpl.jar (from oxygen)

        * resolver.jar (from oxygen)

        * CatalogManager.properties (from oxygen, edited to add custom

        catalogs)

        * path to directory holding all of the above

        * saxon-xml-apis.jar (from XEP)

        * xt.jar (from XEP)

        * crimson.jar (from XEP)

        On Wed, May 7, 2014 at 1:12 PM, Radu Coravu <

        <mailto:>

        <mailto: <mailto:>>> wrote:

             Hi Bergfrid,

             So you are using Docbook 5 (Relax NG based) and have

        xpointers which

             point to a certain ID defined in the target file using

        xml:id, right?

             One possibility of why this works in Oxygen would be the

        fact that

             we have several patches to the Xerces library we are using.

        One of

             them in particular was made to treat "xml:id" as an ID

        attribute

             even if it is not defined as such in the associated schema. The

             thing is that Xerces does not understand the grammar in RelaxNG

             schemas so it cannot determine on its own if a certain

        attribute is

             of type "ID".

             Actually we posted a bug on the Xerces bugs list 7 years

        ago and

             it's still not fixed in their code:

        https://issues.apache.org/____jira/browse/XERCESJ-1113

        <https://issues.apache.org/__jira/browse/XERCESJ-1113>

             <https://issues.apache.org/__jira/browse/XERCESJ-1113

        <https://issues.apache.org/jira/browse/XERCESJ-1113>>

             One thing you could try would be to add in your class path

        from the

             "OXYGEN_INSTALL_DIR" both the "xercesImpl.jar" and the

        "oxygen.jar"

             and make sure the "oxygen.jar" is first added in the

        classpath (so

             that its Xerces patches are used).

             Regards,

             Radu

             Radu Coravu

             <oXygen/>  XML Editor, Schema Editor and XSLT Editor/Debugger

        http://www.oxygenxml.com

             On 5/7/2014 1:30 PM, Bergfrid Skaara wrote:

                 We have a fully functional doc environment with DocBook

        5 and

                 oXygen XML

                 Editor, and I am trying to set up the corresponding java

                 commands for an

                 automated build system. I have combed the DocBook XSL

        book for

                 anything

                 related to xincludes and xpointers, but I still do not

        get why

                 it works

                 from oXygen and not from the command line.

                 Error message: org.xml.sax.SAXParseException [...]

        Reason: XPointer

                 resolution unsuccessful

                 I have the full command line shown in example  23.5

        "XIncludes

                 and XML

                 catalogs with Saxon and Xerces" on page 376.

                 Specs:

                 Saxon 6.5.5, Xerces 2.11.0, oXygen XML Editor 15.1,

        DocBook xsl

                 1.78.1

                 with customization layer and custom rng schema.

                 I use the basic xpointer attribute with fragment

        references to

                 xml:id in

                 the hrefed file. Because this is DB5, there is no

        schema in the

                 DOCTYPE.

                 But according to p46 in DocBook XML TCL, xml:id is

        already mapped to

                 type ID and "you do not have to worry about fragment

        references

                 failing

                 due to lack of schema". After all it does work in the

        oXygen

                 transformation, so why not on the command line with the

        same tools ?

                 Rewriting all xpointers to place this in separate files

        is not an

                 option, as our source is highly modular and

        singlesourced with

                 lots of

                 reuse across documents.

                 Any advice, whether solutions or further reading, are

        welcome.

                 Bergfrid Skaara

             --

        ------------------------------____----------------------------__--__---------

             To unsubscribe, e-mail:

             docbook-apps-unsubscribe@__lis__ts.oasis-open.org

        <http://lists.oasis-open.org>

             <mailto:-open.__org

        <mailto:>>

             For additional commands, e-mail:

        -____open.org

        <mailto:-__open.org>

             <mailto:docbook-apps-help@__lists.oasis-open.org

        <mailto:>>

    --

--