FW: [xmlc] Re: [enhydra] java.lang.StackOverflowError File attached

This is a big show stopper. my project is stalled. Need some help

If the 'syncWithDocument(Node node)' cannot be optimized. Cant the stack
size be increased by mentioning the '-xss' option from appropriate
command line options.


I need a solution Please help. For people viewing this message freshly.
The attached file fails on 'xmlc'


My project is stalled due to this problem.

-rafeeq


 

-----Original Message-----
From: Mohammed Rafeeq [mailto:mrafeeq@xxxxxxx] 
Sent: Thursday, November 30, 2006 1:34 PM
To: enhydra@xxxxxxxxxxxxx
Subject: RE: [xmlc] Re: [enhydra] java.lang.StackOverflowError File
attached

I hit the limit again. Now there is no way that I can change my .html
file to trim down the number of 'id'  attributes. A fix is required.


Please let know which file to change to optimise this.


-rafeeq 

-----Original Message-----
From: Slobodan Vujasinovic [mailto:slobodan@xxxxxxxxxxxxx]
Sent: Wednesday, August 30, 2006 3:07 AM
To: enhydra@xxxxxxxxxxxxx
Subject: Re: [xmlc] Re: [enhydra] java.lang.StackOverflowError File
attached

Hi,

I don't think that recursion is causing  the problem here!

I think that problem lies in large number of 'else if' statements
(inside 'syncWithDocument(Node node)' method) and that this is the part
of code (logic) that needs to get reimplemented (maybe by using some
generic setter methods and/or Map objects).

Regards,
  Slobodan Vujasinovic
Enhydra Development Team



Jacob Kjome wrote:

> At 04:31 PM 8/29/2006, you wrote:
> > My html has grown further  and it has reached the limit again. It 
> >fails to compile.
> >
> >My worry is why is the parameter stack size -xss that I specify in 
> >enhydrahome\ant.bat is not picked up
> >
>
> You'd want to check with the Ant-user list to see how to best set that

> using ant.bat.
>
> >I mention this in xmlc.bat too.
>
> I haven't been distributing a new version of xmlc.bat for quite a 
> while.  It would make sense, but I haven't really gotten around to it.

> For now, it is not a priority, unless you want to contribute it.
> I think there does exist a version in the source, but I haven't 
> modified the build to put this in a proper location in the 
> distribution and I haven't verified how well it works.  You are 
> welcome to look into it.
>
> >
> >A fix is required.
>
> I think we can do more here.  The crux of the matter is determining 
> the best way to avoid excessive recursion.  Again, normally it isn't a

> problem because usually there are not so many Id's.  However, since 
> you do have many Id's, we may as well come up with a solution.  Here's

> a much smaller version of the generated method....
>
>     protected void syncWithDocument(Node node) {
>         if (node instanceof Element) {
>             String id = ((Element)node).getAttribute("id");
>
>             if (id.length() == 0) {
>             } else if (id.equals("hello")) {
>                 $element_Hello =
> (org.enhydra.xml.xhtml.dom.HTMLSpanElement)node;
>             }
>         }
>
>         Node child = node.getFirstChild();
>         while (child != null) {
>             syncWithDocument(child);
>             child = child.getNextSibling();
>         }
>     }
>
> The challenge is to determine the best way to implement this without 
> recursion.  Of course, recursion here makes the code short, sweet, and

> clean.  The problem is that too much recursion brings down the JVM.
> One possibility would be putting first block of code inside a while 
> loop and test the next sibling nodes inside that loop and then 
> evaluating them rather than calling syncWithDocument(Node) 
> recursively.  That would be a pretty straightforward way, but the 
> while loop itself would be massively large in your case.  I'm not sure

> it would matter, but it wouldn't look quite as pretty as the recursive

> version does.  Of course there may be other approaches.  That's why 
> I'm opening this up to a discussion.
>
> I'd like to hear as many suggestions as possible; preferably fully 
> coded solutions.  Code away!!!
>
> Jake
>
> >
> >-rafeeq
> >
> >
> >-----Original Message-----
> >From: Jacob Kjome [mailto:hoju@xxxxxxxx]
> >Sent: Wednesday, August 16, 2006 9:27 PM
> >To: xmlc@xxxxxxxxxxxxx
> >Cc: Mohammed Rafeeq; enhydra@xxxxxxxxxxxxx
> >Subject: RE: [xmlc] Re: [enhydra] java.lang.StackOverflowError File 
> >attached
> >
> >
> >Ok, I think I see the problem.  The java source file is just too big 
> >for the java compiler to handle.  The source file, even with deferred

> >parsing, which stores zero information on how to actually build the 
> >DOM, is 535k and 18,579 lines long!  That's a *lot* of Id's!!!
> >
> >As such, I don't think this is a matter of an XMLC bug, per-say.
> >Though, then thing it seems to be bombing out on is the massive if 
> >statement in the recursive method syncWithDocument(Node node).  The 
> >thing is, normally, this doesn't cause problems.  It's just when this

> >upper limit of Id's is hit.  So, I don't think it's a high priority 
> >issue to search for a fix, but it couldn't hurt to find an 
> >optimization here.
> >
> >I think the approach you took to solving the issue - removing the 
> >excess Id's and taking a different approach in your presentation 
> >object - is the proper one.
> >
> >If anyone has suggestions on improving the generated and recursive 
> >syncWithDocument(Node node) method, I'd be glad to hear it.
> >
> >
> >Jake
> >
> >At 12:59 PM 8/16/2006, Jacob Kjome wrote:
> > >
> > >Glad to hear you were able to work around it.  I will try your
> >original file
> > >when I get home tonight to see if it does, indeed, still fail with
> >deferred
> > >parsing.  If it does, its definitely something that should be
> >investigated and
> > >fixed.  I just noticed that you reported this issue in the XMLC
> >objectweb forge
> > >tracker.  I was going to suggest you do that before I saw that you 
> > >already did.
> > >Thanks!
> > >
> > >Jake
> > >
> > >
> > >Quoting Mohammed Rafeeq <mrafeeq@xxxxxxx>:
> > >
> > >> I am not sure how to check if the command line utility passes the

> > >> "-for-deferred-parsing" flag to XMLC.
> > >>
> > >> Now I cleaned up my html and moved all my javascript, css to
> >external
> > >> files. More over I converted
> > >>
> > >> <td id ="abc"> <input type ="text" id="xyz"></td>
> > >>
> > >> To
> > >>
> > >> <td><input type ="text" id="xyz"></td>
> > >>
> > >> And now it compiles. I changed the way my presentation object is 
> > >> reaching each table cell element and manipulating the content.
> > >>
> > >> But I am still curious enough to know why the earlier file failed

> > >> to compile. If it is a bug in xmlc we can fix it .
> > >>
> > >> Thank you.
> > >> -rafeeq
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Jacob Kjome [mailto:hoju@xxxxxxxx]
> > >> Sent: Wednesday, August 16, 2006 10:07 AM
> > >> To: Mohammed Rafeeq
> > >> Cc: xmlc@xxxxxxxxxxxxx; enhydra@xxxxxxxxxxxxx
> > >> Subject: RE: [xmlc] Re: [enhydra] java.lang.StackOverflowError 
> > >> File attached
> > >>
> > >> Quoting Mohammed Rafeeq <mrafeeq@xxxxxxx>:
> > >>
> > >> > The file that is failing to compile is attached.
> > >> >
> > >> > I tried using deferred parsing  by specifying
> > >> >
> > >> > C:\xmlc -for-deferred-parsing CARGO2QC.html
> > >> >
> > >> > I get the same error
> > >>
> > >> Are you sure that the command line utility you are using passes 
> > >> the "-for-deferred-parsing" flag to XMLC to evaluate as a 
> > >> metadata
> >option?
> > >>
> > >> >
> > >> > I am using I am using enhydra 5.1 and xmlc.jar: 2.2.5.. I am
> >working
> > >> > on Windows xp professional. I tried downloading the latest
> >xmlc.jar
> > >> > but it did not help either. I tried downloading the latest 
> > >> > version enhydra app
> > >> > server(7.x) , created a application and tried to compile this 
> > >> > file
> >,
> > >> > it did not help either.
> > >> >
> > >> > Since this is a show stopper I am proceeding by chopping and
> >reducing
> > >> > a few content in my html file.
> > >> >
> > >>
> > >> Is the full content of the HTML file needed or is some of it just
> >mockup
> > >> markup that could be removed?  You can set a CSS class name to 
> > >> each
> >row
> > >> in the table, such as "removeMe", that is just mockup data and
> >provide
> > >> the XMLC command line option "-delete-class removeMe" or the
XML...
> > >>
> > >> <domEdits>
> > >>         <deleteElement elementClasses="removeMe"/> </domEdits>
> > >>
> > >> > I wanted to debug by downloading the source code. But did not 
> > >> > know
> >how
> > >>
> > >> > to download that particular version from sourceforge.net
> > >> >
> > >>
> > >> You can check out the CVS for the tag XMLC_2_2_X (where X is the
> >version
> > >> you are interested in).  I would try XMLC_2_2_10, since it is the
> >latest
> > >> and has Eclipse project files available for it.  That will make 
> > >> it easier to get up and running.
> > >>  See the following page for information on checking out XMLC CVS 
> > >> source...
> > >>
> > >> http://forge.objectweb.org/scm/?group_id=49
> > >>
> > >> If you don't currently use a CVS client, I recommend using
> >TortoiseCVS
> > >> at http://www.tortoisecvs.org/ .  It makes things easy.  Either 
> > >> go
> >for
> > >> the 1.8.xx versions or the 1.9.11 version.  The latest versions 
> > >> of
> >1.9,
> > >> including 1.9.12 through 1.9.14, seem to suffer from various
> >problems
> > >> that prevent proper usage.
> > >>  I hope 1.9.15 will clear things up, but it isn't out yet.
> > >>
> > >> Jake
> > >>
> > >> > Thanks,
> > >> > -rafeeq
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > -----Original Message-----
> > >> > From: Jacob Kjome [mailto:hoju@xxxxxxxx]
> > >> > Sent: Tuesday, August 15, 2006 9:21 PM
> > >> > To: xmlc@xxxxxxxxxxxxx; enhydra@xxxxxxxxxxxxx
> > >> > Cc: Mohammed Rafeeq
> > >> > Subject: Re: [xmlc] Re: [enhydra] java.lang.StackOverflowError
> > >> >
> > >> >
> > >> > What version of XMLC is being used?  Can you provide the file 
> > >> > that causes the error?  Have you tried using XMLC's deferred 
> > >> > parsing
> > >> feature?
> > >> > I think deferred parsing would solve this issue.
> > >> >
> > >> > Jake
> > >> >
> > >> > At 03:25 AM 8/14/2006, Slobodan Vujasinovic wrote:
> > >> >  >Hi,
> > >> >  >
> > >> >  >I've forwarded your message to XMLC mailing list!
> > >> >  >Maybe someone else already had this problem with large HTML
> >pages!?
> > >> >  >
> > >> >  >Which Enhydra and XMLC versions are you using currently 
> > >> > (please
> >post
> > >> > >your response on XMLC mailing list too - xmlc@xxxxxxxxxxxxx)?
> > >> >  >
> > >> >  >Regards,
> > >> >  >  Slobodan Vujasinovic
> > >> >  >Enhydra Development Team
> > >> >  >
> > >> >  >
> > >> >  >
> > >> >  >mrafeeq@xxxxxxx wrote:
> > >> >  >
> > >> >  >>Hi all
> > >> >  >>
> > >> >  >>I have a big html file ( consisting of 550 <td> cells) . 
> > >> > when i
> >run
> > >>
> > >> > the xmlc  >>  >>When I run the ant task to compile my html to
> >.java
> > >> > files it throws  >an exception like below. ( i run a xmlc task)
> >>>
> > >> >  >>xmlc:
> > >> >  >>    [xmlc]     CARGO2QC.html --> CARGO2QC.class
> > >> >  >>     [xmlc] >>> parsing
> > >> >  >C:\xdx\svndatafinder\src\datafinder\resources\CARGO2QC.html
> > >> >  >>     [xmlc] >>> using DOM Factory class:
> > >> >  >org.enhydra.xml.xmlc.dom.lazydom.LazyHTMLDomFactory
> > >> >  >>     [xmlc] >>> generating code
> > >> >  >>     [xmlc]     creating class:
> > >> >  >C:\xdx\svndatafinder\classes\Generated
> > >> >  >Source\datafinder\presentation\CARGO2QCHTML.java
> > >> >  >>     [xmlc] >>> compiling code
> > >> >  >>     [xmlc] javac -d C:\xdx\svndatafinder\classes -encoding
> > >> >  >ISO-8859-1 C:\xdx\svndatafinder\classes\Generated
> > >> >  >Source\datafinder\presentation\CARGO2QCHTML.java
> > >> >  >>
> > >> >  >>
> > >> >  >>The system is out of resources.
> > >> >  >>Consult the following stack trace for details.
> > >> >  >>java.lang.StackOverflowError
> > >> >  >>     [xmlc] Error: compile of generated java code failed
> > >> >  >>     [xmlc] org.enhydra.xml.xmlc.XMLCException: compile of
> > >> generated
> > >> >  >java code failed
> > >> >  >>     [xmlc]     at
> > >> >
> >>org.enhydra.xml.xmlc.misc.ProcessRunner.run(ProcessRunner.java:283)
> > >> >  >>     [xmlc]     at
> > >> >
> > >>
> >>org.enhydra.xml.xmlc.codegen.JavaCompile.compile(JavaCompile.java:14
> >>5)
> > >> >  >>     [xmlc]     at
> > >> > org.enhydra.xml.xmlc.compiler.Javac.compile(Javac.java:88)
> > >> >  >>     [xmlc]     at
> > >> >
> > >> >
> > >>
>
>>org.enhydra.xml.xmlc.compiler.Compiler.compileJavaSource(Compiler.java
:
> > >> > 153)
> > >> >  >>     [xmlc]     at
> > >> >
> > >> >
>
>>org.enhydra.xml.xmlc.compiler.Compiler.compileDocument(Compiler.java:
> > >> > >18
> > >> > 5)
> > >> >  >>     [xmlc]     at
> > >> >
> >>org.enhydra.xml.xmlc.compiler.Compiler.compile(Compiler.java:226)
> > >> >  >>     [xmlc]     at
> > >> >
>org.enhydra.xml.xmlc.commands.xmlc.XMLC.compile(XMLC.java:132)
> > >> >  >>     [xmlc]     at
> > >> >
> > >> >
> >>org.enhydra.xml.xmlc.commands.xmlc.XMLC.compileHandleErrors(XMLC.jav
> >>a
> > >> > >:1
> > >> > 42)
> > >> >  >>     [xmlc]     at
> > >> > org.enhydra.xml.xmlc.commands.xmlc.XMLC.main(XMLC.java:153)
> > >> >  >>     [xmlc]     at
> > >> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >> >  >>     [xmlc]     at
> > >> >
> > >> >
>
>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> > >> > >ja
> > >> > va:39)
> > >> >  >>     [xmlc]     at
> > >> >
> > >> >
> >>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce
> >>s
> > >> > s
> > >> >  >orImpl.java:25)
> > >> >  >>     [xmlc]     at
> >java.lang.reflect.Method.invoke(Method.java:324)
> > >> >  >>     [xmlc]     at
com.lutris.ant.taskdefs.Xmlc.execute(Unknown
> > >> > Source)
> > >> >  >>     [xmlc]     at
> >org.apache.tools.ant.Task.perform(Task.java:317)
> > >> >  >>     [xmlc]     at
> > >> > org.apache.tools.ant.Target.execute(Target.java:309)
> > >> >  >>     [xmlc]     at
> > >> > org.apache.tools.ant.Target.performTasks(Target.java:334)
> > >> >  >>     [xmlc]     at
> > >> >  >org.apache.tools.ant.Project.executeTarget(Project.java:1306)
> > >> >  >>     [xmlc]     at
> > >> >
>org.apache.tools.ant.Project.executeTargets(Project.java:1250)
> > >> >  >>     [xmlc]     at
> > >> org.apache.tools.ant.Main.runBuild(Main.java:610)
> > >> >  >>     [xmlc]     at
> >org.apache.tools.ant.Main.start(Main.java:196)
> > >> >  >>     [xmlc]     at
> >org.apache.tools.ant.Main.main(Main.java:235)
> > >> >  >>
> > >> >  >>
> > >> >  >>On researching I found out that the java stack is getting
> > >> overflown.
> > >> >  >I tried to increase the java stack size and os stack size by 
> > >> > mentioning  >>  >>%JAVA% -Xms256M -Xmx512M -Xss1000K -Xoss5000K
> >-cp
> > >> > %CLASSPATH% .........
> > >> >  >>
> > >> >  >>in %ENHYDRA_HOME%/bin/ant.bat  >>  >>I am using jdk 1.4.2 
> > >> > and the operating system is windows xp professional.
> > >> >  >>
> > >> >  >>but this did not solve the problem. Any leads will be much 
> > >> > appreciated  >>  >>I have posted this problem in this forum too
> >>>
> > >> >
> >>>http://forums.devx.com/showthread.php?t=155222&highlight=java.lang.
> >>>S
> > >> > >>t
> > >> >  >ackOverflowError
> > >> >  >>
> > >> >  >>Thanksm
> > >> >  >>-Rafeeq(mrafeeq@xxxxxxx)
> > >> >  >>
> > >> >  >>
> > >> >  >>
> > >> >
> > >> >
> >>>-------------------------------------------------------------------
> >>>-
> > >> > >>--
> > >> > --
> > >> >  >>
> > >> >  >>
> > >> >  >>--
> > >> >  >>You receive this message as a subscriber of the 
> > >> > enhydra@xxxxxxxxxxxxx
> > >> > >mailing list.
> > >> >  >>To unsubscribe: mailto:enhydra-unsubscribe@xxxxxxxxxxxxx
> > >> >  >>For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> > >> >  >>ObjectWeb mailing lists service home page:
> > >> > http://www.objectweb.org/wws  >>  >>  >  >  >
> > >> >  >--
> > >> >  >You receive this message as a subscriber of the
> >xmlc@xxxxxxxxxxxxx
> > >> > >mailing list.
> > >> >  >To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
> > >> >  >For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> > >> >  >ObjectWeb mailing lists service home page:
> > >> > http://www.objectweb.org/wws
> > >> >
> > >> >
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> > >--
> > >You receive this message as a subscriber of the xmlc@xxxxxxxxxxxxx 
> > >mailing list.
> > >To unsubscribe: mailto:xmlc-unsubscribe@xxxxxxxxxxxxx
> > >For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
> > >ObjectWeb mailing lists service home page:
> >http://www.objectweb.org/wws
>
>
>-----------------------------------------------------------------------
>-
>
>
>--
>You receive this message as a subscriber of the enhydra@xxxxxxxxxxxxx
mailing list.
>To unsubscribe: mailto:enhydra-unsubscribe@xxxxxxxxxxxxx
>For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
>ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>  
>

LARGOQCeCRFViewPO.java
Description: LARGOQCeCRFViewPO.java

--
You receive this message as a subscriber of the enhydra@xxxxxxxxxxxxx mailing 
list.
To unsubscribe: mailto:enhydra-unsubscribe@xxxxxxxxxxxxx
For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws