You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Tim Williams <wi...@gmail.com> on 2006/01/29 21:52:44 UTC
jxpath problems
On 1/29/06, Thorsten Scherler <th...@apache.org> wrote:
> El dom, 29-01-2006 a las 12:57 +0100, Thorsten Scherler escribió:
> > El dom, 29-01-2006 a las 18:23 +1100, David Crossley escribió:
> > > Tim Williams wrote:
> > > > I've followed the quickstart[1] with the Photogallery plugin and get
> > > > either OutOfMemory exceptions or (if I get silly with a memory
> > > > increase) get a StackOverflowError exception. I can use the
> > > > Dispacther successfully on a simple seed site though. I'm not asking
> > > > for anyone to expend resources fully troubleshooting this but if
> > > > someone could confirm/deny the errors I'd appreciate it.
> > >
> > > I get the same error trying to Dispatcher-enable the
> > > PhotoGallery plugin's own website.
> > >
> > > I do have a site that actually uses the plugin.
> > > When i try to Dispatcher-enable that site, it fails on
> > > the Gallery parts with "No pipeline matched request: gallery/practice/index_1.xml"
> > >
> >
> > Actually that becomes a faq for v2. ;-)
> > http://marc.theaimsgroup.com/?l=forrest-dev&m=113775018214915&w=2
> >
> > and
> >
> > http://issues.apache.org/jira/browse/FOR-738
> >
> > First I thought that maybe as well FOR-725 but does not seems like it
> > (it worked for me after the following).
> >
> > When I commend
> > <!--<forrestPlugins label="Plugins Index" href="site:forrest/plugins"
> > description="Index of Forrest Plugins"/>-->
> >
> > Then it is working fine. I tried with the new plugins but the site: is
> > still broken there. Meaning the jx:stuff is again broken and we need to
> > fix Davids workaround. :(
> >
> > Help greatly appreciated.
> >
>
> Actually I played a bit with it but I guess it needs a real good debug.
>
> One observation I made is that:
> <forrestPlugins label="Plugins Index" href="site:forrest/plugins"
> description="Index of Forrest Plugins"/>
>
> should actually be
> <forrestPlugins label="Plugins Index" href="ext:forrest/plugins"
> description="Index of Forrest Plugins"/>
>
> because the referenced link is in the
> <external-refs>
> <forrest href="http://forrest.apache.org/">
> <plugins href="docs/plugins"/>
> </forrest>
> </external-refs>
>
> but still I get an java.lang.OutOfMemoryError :(
>
> I removed all indirections and still java.lang.OutOfMemoryError.
>
> IMO this bug is related again to jx and the linkrewritter.
>
> salu2
> --
> thorsten
>
> "Together we stand, divided we fall!"
> Hey you (Pink Floyd)
Thanks for looking into this. I've now had a look at the stack trace
for these errors and a significant portion relate to dispose() method
in TransformerAdapter. It appears to have a bug in it by setting the
parserContext to null, then attempting to access it. I wouldn't
imagine that this is our real problem but it certainly is a huge
portion of my core.log. Unfortunately, Cocoon has recently made the
the build process too difficult for me to manage. I've spent the last
hour just trying to build an out of the box Cocoon with m2 and it
tries to download half the internet before finally failing. Anyway,
if you can get Cocoon compiled maybe you can try applying the
following patch to the template block and see if it reduces the errors
a bit.
Index: trunk/java/org/apache/cocoon/template/TransformerAdapter.java
===================================================================
--- trunk/java/org/apache/cocoon/template/TransformerAdapter.java (revision
366548)
+++ trunk/java/org/apache/cocoon/template/TransformerAdapter.java (working copy)
@@ -61,9 +61,9 @@
}
public void dispose() {
- setParsingContext( null );
this.manager.release(this.parsingContext.getInstructionFactory());
this.manager.release(this.parsingContext.getStringTemplateParser());
+ setParsingContext( null );
}
public void endDocument() throws SAXException {
I assume you've seen the comment?
/**
* Adapter that makes this generator usable as a transformer (Note there is a
* performance penalty for this however: you effectively recompile the template
* for every instance document)
*
* @version SVN $Id: TransformerAdapter.java 325973 2005-10-17
19:59:39Z lgawron $
*/
I'll give a cocoon a little more time before I just give up.
--tim
Re: jxpath problems
Posted by Thorsten Scherler <th...@apache.org>.
El dom, 29-01-2006 a las 15:52 -0500, Tim Williams escribió:
> O
...
> Thanks for looking into this. I've now had a look at the stack trace
> for these errors and a significant portion relate to dispose() method
> in TransformerAdapter. It appears to have a bug in it by setting the
> parserContext to null, then attempting to access it. I wouldn't
> imagine that this is our real problem but it certainly is a huge
> portion of my core.log. Unfortunately, Cocoon has recently made the
> the build process too difficult for me to manage. I've spent the last
> hour just trying to build an out of the box Cocoon with m2 and it
> tries to download half the internet before finally failing. Anyway,
> if you can get Cocoon compiled maybe you can try applying the
> following patch to the template block and see if it reduces the errors
> a bit.
Sorry, I cannot give you a hand on this one because I did not follow the
maven move to close. ...but maybe somebody else. ;-)
Anyway your findings are very valuable and maybe it makes sense that you
ask in cocoon whether you can apply this fix to their code (you have
write access there). ;-) I think that they are very good findings.
Thanks Tim.
>
> Index: trunk/java/org/apache/cocoon/template/TransformerAdapter.java
> ===================================================================
> --- trunk/java/org/apache/cocoon/template/TransformerAdapter.java (revision
> 366548)
> +++ trunk/java/org/apache/cocoon/template/TransformerAdapter.java (working copy)
> @@ -61,9 +61,9 @@
> }
>
> public void dispose() {
> - setParsingContext( null );
> this.manager.release(this.parsingContext.getInstructionFactory());
> this.manager.release(this.parsingContext.getStringTemplateParser());
> + setParsingContext( null );
> }
>
> public void endDocument() throws SAXException {
>
> I assume you've seen the comment?
Hmm, I should have but I think I did not realize the "performance
penalty" of the transformer. :(
I will switch to jx-generator where ever possible. Thanks for the
headsup. :)
> /**
> * Adapter that makes this generator usable as a transformer (Note there is a
> * performance penalty for this however: you effectively recompile the template
> * for every instance document)
> *
> * @version SVN $Id: TransformerAdapter.java 325973 2005-10-17
> 19:59:39Z lgawron $
> */
>
> I'll give a cocoon a little more time before I just give up.
> --tim
Good on ya mate.
BTW I fixed the OutOfMemory exception that you had with the
Photogallery. In the end it was the way we called the linkmap (I think
that skins as well can lead to the behavior but not to the final
exception).
Thx for looking into the jx stuff, you helped again to make the
dispatcher faster when I finished using jx-generators.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: jxpath problems
Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
>
> Thanks for looking into this. I've now had a look at the stack trace
> for these errors and a significant portion relate to dispose() method
> in TransformerAdapter. It appears to have a bug in it by setting the
> parserContext to null, then attempting to access it. I wouldn't
> imagine that this is our real problem but it certainly is a huge
> portion of my core.log. Unfortunately, Cocoon has recently made the
> the build process too difficult for me to manage. I've spent the last
> hour just trying to build an out of the box Cocoon with m2 and it
> tries to download half the internet before finally failing.
:-) ... the previous Cocoon pre-packaged that for us :-)
To be fair they are still in the middle of refactoring
the build system. There is a doc somewhere explaining
how to get up-to-speed (search their Daisy). Also perhaps
ask for help on dev@cocoon.
This is why i said a while ago that we should stick
to the last known version of Cocoon's Ant-based build.
If there is some "must-have" functionality that we need
important bugfix, then we can apply patches to that old
version. I listed the svn revision number recently in
our dev- archives.
However that becomes a management nightmare. So we
would not want to release like that. But for testing
and development it will allow a workaround.
-David