DefaultDocument comes from a Jelly library, while DefaultHandler is from a WebSphere jar:
class org.dom4j.tree.DefaultDocument loaded from wsjar:file:/C:/Documents and Settings/usr/Desktop/commons-jelly-1.0/lib/dom4j-1.5.2.jar!/org/dom4j/tree/DefaultDocument.class class org.xml.sax.helpers.DefaultHandler loaded from jar:file:/C:/Program%20Files/ibm/WebSphere/AppServer1/java/jre/lib/xml.jar!/org/xml/sax/helpers/DefaultHandler.class 2011/4/30 Paul Libbrecht <p...@hoplahup.net>: > Here's a little script that will tell you the URL of classes of interest: > > <j:jelly trim="false" xmlns:j="jelly:core"> > > <j:new var="x" className="org.dom4j.tree.DefaultDocument"/> > class ${x.getClass()} loaded from > ${x.getClass().getResource('DefaultDocument.class')} > > <j:new var="x" className="org.xml.sax.helpers.DefaultHandler"/> > class ${x.getClass()} loaded from > ${x.getClass().getResource('DefaultHandler.class')} > > </j:jelly> > > With some chances, your URLs are of the form file:///xxxxx.jar!a/b/c/d/e.class > If you have a special protocol-handler, it may be harder. > > paul > > > Le 30 avr. 2011 à 15:40, Csaba Győrffy a écrit : > >> Hi, >> >> thank you very much for your responses. I'm already trying to >> determine the version of xml parser without much success yet. >> >> Csaba >> >> 2011/4/30 Martin Gainty <mgai...@hotmail.com>: >>> >>> trying not to point fingers (at least until we have ALL the facts) >>> a similar incident happened on another apache project and an older version >>> of xml-parser was at fault >>> trying to determine the implemented xml-parser and the version in this case >>> would *at least* isolate the problem to that parser >>> >>> thanks paul! >>> Martin >>> ______________________________________________ >>> Jogi és Bizalmassági kinyilatkoztatás >>> Ez az >>> üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy >>> jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának >>> készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és >>> semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek >>> könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet >>> ezen üzenet tartalma miatt. >>> >>> >>> >>> >>> >>>> Subject: Re: [Jelly] XML ForEach tag hangs >>>> From: p...@hoplahup.net >>>> Date: Sat, 30 Apr 2011 09:44:27 +0200 >>>> To: user@commons.apache.org >>>> >>>> Csaba, >>>> >>>> As Martin has suggested, the underlying XML parser could be guilty. >>>> I would rather suspect an overly old dom4j or jaxen (that would be in the >>>> container's classpath hence overriding the webapp's). >>>> >>>> Are you able to find their version? >>>> Otherwise I can dig out a form of jwhich in jelly. >>>> >>>> paul >>>> >>>> >>>> Le 30 avr. 2011 à 03:02, Csaba Győrffy a écrit : >>>> >>>>> Hello there! >>>>> >>>>> I'm trying to use the ForEach tag in Jelly's XML tag library. The >>>>> following script works fine in a standard Java console application: >>>>> >>>>> <x:parse var="doc"> >>>>> <a> >>>>> <b v="1"/> >>>>> <b v="2"/> >>>>> <b v="3"/> >>>>> </a> >>>>> </x:parse> >>>>> >>>>> <x:forEach select="$doc/a/b" var="x"> >>>>> ... >>>>> </x:forEach> >>>>> >>>>> However, if using Jelly on an application server, from inside an EJB >>>>> container (session bean), running the script above hangs, and 100% CPU >>>>> utilisation comes. I realized while debugging that NodeComparator >>>>> class' getDepth method gets into an infinite loop and never returns. >>>>> >>>>> If I remove two "b" elements from the xml fragment above (so only one >>>>> remains), it works fine. It also works if I change the second part of >>>>> the above script to the following: >>>>> >>>>> <x:forEach select="$doc/a"> >>>>> <x:forEach select="b"> >>>>> ... >>>>> </x:forEach> >>>>> </x:forEach> >>>>> >>>>> Does anyone have any idea why is that happening? Any help is much >>>>> appreciated. >>>>> >>>>> Thank you: >>>>> Csaba >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: user-h...@commons.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: user-h...@commons.apache.org >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >> For additional commands, e-mail: user-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org