You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Ulrich Mayring <ul...@denic.de> on 2000/07/07 13:27:48 UTC
How to reduce the size of XSP classes?
Hi all,
I ran into the "Code of a method longer than 65535 bytes" error. It's an
XSP page, but it has only a minimal amount of logic. The reason why the
cocoon-generated class is so big, are the many regular XML tags in the
XML file.
So, if it was my code that was too large, I could package and jar it and
put it in the classpath instead of in an XSP taglib. However, the
problem is the size of the XML, and that I cannot reduce. So, what can I
do?
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: How to reduce the size of XSP classes?
Posted by Uli Mayring <ul...@denic.de>.
On Fri, 7 Jul 2000, Mark Washeim wrote:
> 1. If you don't treat the nodes but only want to add something like date,
> then definatly use xinclude (or util:include-file). That will only includ
> eht content at request time, not compile time.
util:include-file is an XSP taglib, so it won't work. I can use it only in
XSP pages and XSP pages are compiled, no matter what. I presented the
counter example as an example of the kind of information I want to
include. It's dynamic information like whether some file exists, when a
file was last modified etc. These things are - like a counter - subject
to change external to cocoon.
> 2. If it's something like date/time you want to include, have Xinclude
> include the xsp page (as a URI, so, with network overhead) as a 'fragment'
> of the secondary page... you could have lots of utility 'pages' . . . but,
> then, we're in jetspeed territory and you might want to look at portlets .
That might just work. You mean I write an XSP page for all my dynamic
stuff (which basically just generates new XML tags) and XInclude this XSP
page into my XML page? But I see two problems here:
1) How do I tell cocoon to first process the XIncluded XSP page and
XInclude only the resulting tags?
2) How do I pass information to the XIncluded XSP page? The XSP page needs
to know which XML file it is being included in (there could be many).
> 3. use two xslt passes, transforming the data of the large data set
> 'through' an xslt/xsp page . . . but I've never tried this. The idea is:
> xml -> xslt -> xslt/xsp -> html
My current approach is XML -> XSLT/XSP -> XSLT -> HTML
I can tell you this doesn't work, cocoon compiles the XML page. Your
approach would mean that in the first XSLT pass I need to get rid of lots
of data, thereby staying under 64KB in the XSLT/XSP pass?
> I'd be interesting to try this with xsp. Namely, aggregate the results of
> numerous documents.
>
> I'm going to have a go at this. But, first, with xinclude such that:
> mailarchive.xml is composed of:
> <xinclude:include parse="xml"
> href="nav/site.xml#xpointer(//somestructure)"/>
> <xinclude:include parse="xml"
> href="util/calendar.xml#xpointer(//date/time)"/>
> <xinclude:include parse="xml" href
> ="mail/archive.xml#xpointer(//whatever)"/
> <xinclude:include parse="xml"
> href="colophon/colophon.xml#xpointer(//colophon/copyright)"/>
Yeah, looks nice, but how do I make util/calendar.xml actually perform
some calculation upon inclusion into another file?
I had another idea, but it involved doing an XSP pass first and an
XInclude pass later (which currently doesn't work with the XInclude
processor). Basically the idea involved simply ignoring the original
(large) XML and do the XSP stuff first and then later on XInclude the
original page again. But, apart from the problem that XInclude doesn't
work after XSP, I wouldn't know how to implement such a workflow either :)
So, please nobody tell me I have to go back to PHP :-)
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: How to reduce the size of XSP classes?
Posted by Mark Washeim <es...@canuck.com>.
on 7/7/00 3:18 pm, Ulrich Mayring at ulim@denic.de wrote:
> Mark Washeim wrote:
>>
>> Can I ask what the nature of the content is?
>
> Yes, I am writing an XML-based email archive. When I have 125 email
> subject lines on my overview page, then that equals about 20K XML code.
> The XML file is smaller than the HTML page generated from it.
>
>> It seems that you might only require some number of elements for any given
>> view. Hence, you could take an approach like xinclude does, and treat only
>> those nodes required for a given view?
> Let's assume for this example that we want to have some very simple
> logic, a counter, on every page. But we are not allowed to use the
> XSPProcessor, because it will always try to compile. That leaves us with
> the SQL Processor and the XInclude Processor. The first is out, because
> I don't want to do all my logic in a database :-)
>
> Perhaps there's some way to trick the XSPProcessor by using XInclude.
>
Ok, I've got you. Three immediate solutions come to mind:
1. If you don't treat the nodes but only want to add something like date,
then definatly use xinclude (or util:include-file). That will only includ
eht content at request time, not compile time.
2. If it's something like date/time you want to include, have Xinclude
include the xsp page (as a URI, so, with network overhead) as a 'fragment'
of the secondary page... you could have lots of utility 'pages' . . . but,
then, we're in jetspeed territory and you might want to look at portlets . .
.
3. use two xslt passes, transforming the data of the large data set
'through' an xslt/xsp page . . . but I've never tried this. The idea is:
xml -> xslt -> xslt/xsp -> html
I need to try something like this . . .
The 2nd idea is one of aggregation that Kevin of the jetspeed project is
doing very tidily with a portal defined of numerous portlets. . .
I'd be interesting to try this with xsp. Namely, aggregate the results of
numerous documents.
I'm going to have a go at this. But, first, with xinclude such that:
mailarchive.xml is composed of:
<xinclude:include parse="xml"
href="nav/site.xml#xpointer(//somestructure)"/>
<xinclude:include parse="xml"
href="util/calendar.xml#xpointer(//date/time)"/>
<xinclude:include parse="xml" href="mail/archive.xml#xpointer(//whatever)"/
<xinclude:include parse="xml"
href="colophon/colophon.xml#xpointer(//colophon/copyright)"/>
Of course, I'm not sure about what the impact on performance is, etc.
>> Or, do you really have 20KB of text to display? Our average article and all
>> it associated text (xml) are rarely more than 1 to 2 KB....
>
> Perhaps you have no "Terms of Business"? ;-)
>
> Seriously, our terms of business document is very large, just as an
> example.
>
> Ulrich
yeah, sorry, I didn't mean to oversimplify. :)
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: How to reduce the size of XSP classes?
Posted by Ulrich Mayring <ul...@denic.de>.
Mark Washeim wrote:
>
> Can I ask what the nature of the content is?
Yes, I am writing an XML-based email archive. When I have 125 email
subject lines on my overview page, then that equals about 20K XML code.
The XML file is smaller than the HTML page generated from it.
> It seems that you might only require some number of elements for any given
> view. Hence, you could take an approach like xinclude does, and treat only
> those nodes required for a given view?
Let's assume for this example that we want to have some very simple
logic, a counter, on every page. But we are not allowed to use the
XSPProcessor, because it will always try to compile. That leaves us with
the SQL Processor and the XInclude Processor. The first is out, because
I don't want to do all my logic in a database :-)
Perhaps there's some way to trick the XSPProcessor by using XInclude.
> Or, do you really have 20KB of text to display? Our average article and all
> it associated text (xml) are rarely more than 1 to 2 KB....
Perhaps you have no "Terms of Business"? ;-)
Seriously, our terms of business document is very large, just as an
example.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: How to reduce the size of XSP classes?
Posted by Mark Washeim <es...@canuck.com>.
on 7/7/00 1:57 pm, Ulrich Mayring at ulim@denic.de wrote:
> Hugues Marilleau wrote:
>>
>> Maybe you can split your XML file into differents parts and reassemble it ?
>> It is not very elegant, but if it works ...
>
> Well, that means I cannot use XML files larger than 20 KBytes with the
> XSP processor (about 20K XML and cocoon's XSP overhead add up to 64K in
> my case). That would be bad news indeed. I cannot possibly split up all
> of our XML files that are larger than 20 KB.
>
> Ulrich
Can I ask what the nature of the content is?
It seems that you might only require some number of elements for any given
view. Hence, you could take an approach like xinclude does, and treat only
those nodes required for a given view?
Or, do you really have 20KB of text to display? Our average article and all
it associated text (xml) are rarely more than 1 to 2 KB....
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: How to reduce the size of XSP classes?
Posted by Ulrich Mayring <ul...@denic.de>.
Hugues Marilleau wrote:
>
> Maybe you can split your XML file into differents parts and reassemble it ?
> It is not very elegant, but if it works ...
Well, that means I cannot use XML files larger than 20 KBytes with the
XSP processor (about 20K XML and cocoon's XSP overhead add up to 64K in
my case). That would be bad news indeed. I cannot possibly split up all
of our XML files that are larger than 20 KB.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Newbie question...
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Donald Ball" <ba...@webslingerZ.com>
Sent: Friday, July 07, 2000 9:27 PM
> On Fri, 7 Jul 2000, Per Kreipke wrote:
>
> > > you must be kidding - although i know people who swear by slickedit and/or
> > visualage.
> >
> > a man can dream can't he?
> >
> > I've also heard good things about visual age.
> >
> > Is your vigor from a philosophical bent or because there aren't any XSP or
> > Java/XML editors?
>
> my vigor? you mean the fact that i use vim? mainly it's because i don't
> have the time to climb the learning curve for something like slickedit or
> visualage. :)
>
I use JBuilder 3.5 Foundation for the Java part, it's free and works well.
The nice thing is that it's file based (VisualAge has a repository) and
not necessarily visual (ie it doesn't mess with your code).
Ken
Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Personal homepage at Java Guru:
http://www.jguru.com/jguru/guru/viewchannel.jsp?EID=39153
Personal FAQ at Java Guru:
http://www.jguru.com/jguru/guru/viewfaqs.jsp?EID=39153
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)
RE: Newbie question...
Posted by Uli Mayring <ul...@denic.de>.
On Fri, 7 Jul 2000, Donald Ball wrote:
> my vigor? you mean the fact that i use vim? mainly it's because i don't
> have the time to climb the learning curve for something like slickedit or
> visualage. :)
Let me tell you about PowerJ. Then again... it's week-end :)
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
RE: Newbie question...
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 7 Jul 2000, Per Kreipke wrote:
> > you must be kidding - although i know people who swear by slickedit and/or
> visualage.
>
> a man can dream can't he?
>
> I've also heard good things about visual age.
>
> Is your vigor from a philosophical bent or because there aren't any XSP or
> Java/XML editors?
my vigor? you mean the fact that i use vim? mainly it's because i don't
have the time to climb the learning curve for something like slickedit or
visualage. :)
- donald
RE: Newbie question...
Posted by Per Kreipke <pe...@onclave.com>.
> you must be kidding - although i know people who swear by slickedit and/or
visualage.
a man can dream can't he?
I've also heard good things about visual age.
Is your vigor from a philosophical bent or because there aren't any XSP or
Java/XML editors?
per.
Re: Newbie question...
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 7 Jul 2000, Per Kreipke wrote:
> I'd like to get started with Cocoon but I'm not so happy with the
> development environment I have - none.
>
> What tools are people recommending/using for:
>
> - Java coding (i.e. Cocoon development)?
> - XML editing (XML XSLT, etc)?
vim. it's got nice color highlighting for java and xml.
> - debugging (XSP, etc.)?
jdb and looking at the generated source in the repository.
> - integrated environment?
you must be kidding - although i know people who swear by slickedit and/or
visualage.
- donald
Re: Newbie question...
Posted by Uli Mayring <ul...@denic.de>.
On Fri, 7 Jul 2000, Per Kreipke wrote:
> I'm hoping the answers aren't vi and notepad :-)
Heh, I use pico (pine's text editor) and JDK :-)
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Newbie question...
Posted by Per Kreipke <pe...@onclave.com>.
I'd like to get started with Cocoon but I'm not so happy with the
development environment I have - none.
What tools are people recommending/using for:
- Java coding (i.e. Cocoon development)?
- XML editing (XML XSLT, etc)?
- debugging (XSP, etc.)?
- integrated environment?
Platforms:
- in Windows?
- in Unix?
I'm hoping the answers aren't vi and notepad :-)
Is there an on-line resource that discusses this? E.g. somewhere in the
development/contribute notes.
Thanks for indulging me,
Per Kreipke
Re: How to reduce the size of XSP classes?
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 7 Jul 2000, Hugues Marilleau wrote:
> On Fri, Jul 07, 2000 at 01:27:48PM +0200, Ulrich Mayring wrote :
> > Hi all,
> >
> > I ran into the "Code of a method longer than 65535 bytes" error. It's an
> > XSP page, but it has only a minimal amount of logic. The reason why the
> > cocoon-generated class is so big, are the many regular XML tags in the
> > XML file.
> >
> > So, if it was my code that was too large, I could package and jar it and
> > put it in the classpath instead of in an XSP taglib. However, the
> > problem is the size of the XML, and that I cannot reduce. So, what can I
> > do?
> >
>
> Maybe you can split your XML file into differents parts and reassemble it ?
> It is not very elegant, but if it works ...
Aw, c'mon, that's a junky workaround. How do the JSP guys get around this?
- donald
Re: How to reduce the size of XSP classes?
Posted by Hugues Marilleau <hu...@xenon.medisite.net>.
On Fri, Jul 07, 2000 at 01:27:48PM +0200, Ulrich Mayring wrote :
> Hi all,
>
> I ran into the "Code of a method longer than 65535 bytes" error. It's an
> XSP page, but it has only a minimal amount of logic. The reason why the
> cocoon-generated class is so big, are the many regular XML tags in the
> XML file.
>
> So, if it was my code that was too large, I could package and jar it and
> put it in the classpath instead of in an XSP taglib. However, the
> problem is the size of the XML, and that I cannot reduce. So, what can I
> do?
>
Maybe you can split your XML file into differents parts and reassemble it ?
It is not very elegant, but if it works ...
Re: How to reduce the size of XSP classes?
Posted by Zvi <th...@ifrance.com>.
Hi,
I think, that XSP Java code generator, should be modified, to split
populateDocument() method into several public methods, each of them can be upto
64K. The methods should be public, to disable methods inlining.
Zvi.
Ulrich Mayring wrote:
> Jay Cain wrote:
> >
> > The content of the <mydocument> element is put into the populateDocument()
> > method, which is the build-in function for generating the document, the
> > code
> > inside that element cannot be greater than 64KB. However, the doStuff()
> > method can itself be up to 64KB.
>
> Yes, that's a good idea, but how can I make doStuff() copy over the
> original XML to my stylesheet? My problem is not the size of my custom
> logic, but the size of the XML.
>
> Ulrich
>
> --
> Ulrich Mayring
> DENIC eG, Systementwicklung
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: How to reduce the size of XSP classes?
Posted by Ulrich Mayring <ul...@denic.de>.
Jay Cain wrote:
>
> The content of the <mydocument> element is put into the populateDocument()
> method, which is the build-in function for generating the document, the
> code
> inside that element cannot be greater than 64KB. However, the doStuff()
> method can itself be up to 64KB.
Yes, that's a good idea, but how can I make doStuff() copy over the
original XML to my stylesheet? My problem is not the size of my custom
logic, but the size of the XML.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
RE: How to reduce the size of XSP classes?
Posted by Jay Cain <ja...@enetsouth.com>.
Ulrich Mayring,
> So, if it was my code that was too large, I could package and
> jar it and
> put it in the classpath instead of in an XSP taglib. However, the
> problem is the size of the XML, and that I cannot reduce. So,
> what can I
> do?
The 64KB limitation is a per-method limitation imposed by the Java
architechure. You can get around your problem by breaking you page into
methods. Each method would have the same 64K limit, but there can be up to
64K methods in a Java class, which, of course, would put your class file
around 4GB. Needless to say, there is plenty of space, you just have to
break up your page into multiple methods.
There is an XSP element called <xsp:declare-node-stack> declares the
xspParentNode, xspCurrentNode, xspNodeStack, and document variables for your
function. The element takes one attribute: node-argument. The value of this
is the name of the variable that contains the context node. Here's an
example of its use:
<xsp:page ...>
<xsp:logic>
void doStuff(Node currentNode, ...) {
<xsp:declare-node-stack node-argument="currentNode" />
...code and elements...
<mytag1>
...etc...
</mytag1>
...etc...
}
<xsp:logic>
<mydocument>
<xsp:logic>
doStuff(xspCurrentNode, ...);
</xsp:logic>
</mydocument>
</xsp:page>
The content of the <mydocument> element is put into the populateDocument()
method, which is the build-in function for generating the document, the code
inside that element cannot be greater than 64KB. However, the doStuff()
method can itself be up to 64KB.
------------------
Jay Cain
Lead Developer
eNetSouth, LLC
jay@enetsouth.com