Return-Path: <ricardo@apache.org>
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 4679 invoked from network); 27 Apr 2000 21:05:49 -0000
Received: from cr2167256193.cable.net.co (HELO ricardo.plenix.com)
 (root@216.72.56.193)
  by locus.apache.org with SMTP; 27 Apr 2000 21:05:49 -0000
Received: from ricardo (IDENT:ricardo@localhost.localdomain [127.0.0.1])
	by ricardo.plenix.com (8.9.3/8.8.7) with SMTP id QAA06906
	for <cocoon-dev@xml.apache.org>; Thu, 27 Apr 2000 16:05:25 -0500
From: Ricardo Rocha <ricardo@apache.org>
Reply-To: ricardo@apache.org
To: cocoon-dev@xml.apache.org
Subject: RE: XSP size limit??
Date: Thu, 27 Apr 2000 15:42:17 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <00042716052406.05222@ricardo>
Content-Transfer-Encoding: 8bit
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

Mike Engelhart wrote: 
> 
> I've been successfully using XSP for a few months now and have not run into 
> anything like this. I have an XSP file that is only 35K in size. It's a 
> well-formed document according to tidy so I've skipped that as a possible 
> problem. Anyway, I can't get this file to work.. When I try and access the 
> file with my browser, according to top, java just takes over the CPU and 
> spins forever. When I look in the repository directory there is a .java and 
> .class file. The class file is a portly 350K!!!! :-)

Big XSP pages with a lot of static markup may easily generate Java classes
whose "populateDocument" method exceeds the JVM-imposed 64K size limit:

      java.lang.ClassFormatError: Code of a method longer than 65535 bytes

The main culprits:

1) lots of string constants in the generated method (element and attribute
    names, constant text nodes),
2) stack management code (xspParentNode, xspCurrentNode)

Both of these problems will go away as we move towards a SAX-based
XSP implementation in Cocoon2.

Fixing this for Cocoon1 involves an extensive revision of the builtin
"java-xsp.xsl" logicsheet, something we should probably defer in favor of
working on Cocoon2's XSP implementation...

In the meantime, a suitable workaround is to replace static, repetitive
markup by logic as illustrated in the example below.

Instead of a long list of nested elements like:

    <selectcountry selected="US">
      <country>
        <value>AF</value>
        <name>Afghanistan</name>
      </country>
      . . . LOTS OF COUNTRIES ...
      <country>
        <value>ZW</value>
        <name>Zimbabwe</name>
      </country>
    </selectcountry>

one may define a static, class-level array:

    <xsp:page>
      <xsp:logic>
        static String[][] countries = {
          { "AF", "Afghanistan" },
           . . .
          { "ZW", "Zimbawe" },
        }
      </xsp:logic>
      ... STUFF ...
    </xsp:page>

and dynamically generate the "selectcountry" element like:

    <selectcountry selected="US">
      <xsp:logic>
        for (int i = 0; i < countries.length; i++) {
          <country>
            <value><xsp:expr>countries[i][0]</xsp:expr></value>
            <name><xsp:expr>countries[i][0]</xsp:expr></name>
          </country>
        }
      </xsp:logic>
    </selectcountry>

inside the document's body.

Hope this helps...

Ricardo