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
