Remedy is

http://www.mail-archive.com/xalan-j-users@xml.apache.org/msg04890.html

copy and paste from the above link

[

Hello, Erik.   

I was struggling with this problem back in November 2005, but after some
poking around I found a one-line change that has eliminated all "No more
DTM IDs" errors on my project.

I unpacked xalan_2_7_0.jar and in
src/org/apache/xml/dtm/DTMManager.java, line 362, I found, read, and (I
hope) understood this comment:

  /** This value, set at compile time, controls how many bits of the
   * DTM node identifier numbers are used to identify a node within a
   * document, and thus sets the maximum number of nodes per
   * document. The remaining bits are used to identify the DTM
   * document which contains this node.
   *
   * If you change IDENT_DTM_NODE_BITS, be sure to rebuild _ALL_ the
   * files which use it... including the IDKey testcases.
   *
   * (FuncGenerateKey currently uses the node identifier directly and
   * thus is affected when this changes. The IDKEY results will still be
   * _correct_ (presuming no other breakage), but simple equality
   * comparison against the previous "golden" files will probably
   * complain.)
   * */

I then changed the following constant's value from 16 to 12.

  public static final int IDENT_DTM_NODE_BITS = 12;

Then I added a little static initializer purely to convince myself that
my webserver actually found my copy of xalan.jar

  static {
     System.out.println(" IDENT_DTM_NODE_BITS: "+ IDENT_DTM_NODE_BITS );
  }

My understanding of this change is that I gave up four (16-12) bits
worth of IDs for identifying documents, in exchange for four more bits
of node IDs within each document.  I cannot imagine in my app needing
more than 2^12 (4096) document IDs, but I certainly need more than 2^16
(65536) worth of nodes within a document.  Now I can have up to 2^20
(1,048,576) nodes per document.

Now, maybe some more knowledgable xalan developers can answer this:  In
the above comment, it says: " If you change IDENT_DTM_NODE_BITS, be sure
to rebuild _ALL_ the files which use it... including the IDKey
testcases.".  Now, I did rebuild the entire package, which I am sure
satisfies that requirement, but why does it have to be a compile-time
setting?   Since other classes would have to refer to
DTMManager.IDENT_DTM_NODE_BITS (AFAIK, referring to a final variable
like this doesn't actually COPY the value into the other classes, or
does it?)   Would it not also work to provide 16 as a default, but allow
it to be overridden, like this?

    public static final int IDENT_DTM_NODE_BITS = 

Integer.parseInt(System.getProperty("org.apache.xml.dtm.DTMManager.IDENT
_DTM_NODE_BITS"), "16");

Then people who need another value can simply start their app with 
  -Dorg.apache.xml.Dorg.apache.xml.dtm.DTMManager.IDENT_DTM_NODE_BITS=12
on the command line and be done with it.

If there is a downside to what I have done, PLEASE discuss!  So far, I
do not see one!

tlj

Timothy Jones - Sr. Systems Engineer, Development 
(813) 637-5366 - Syniverse Technologies 
Learn a new language, grow a new soul, live a new life.

]

Advertisements