Hi Paul, please see my answers below.
> Can you try:
>
> <x:parse var="doc">
> <a>
> <b v="1"/>
> <b v="2"/>
> <b v="3"/>
> </a>
> </x:parse>
>
> <x:set select="$doc/a/b" var="x"/>
>
> x is ${x} of class ${x.getClass()} and of size ${size(x)}
>
>
> does it also spin 100%?
>
Yes, it is:/
> Also, could you please try to see the origin a jaxen class? (e.g.
> org.jaxen.Context ?)
Origin of org.jaxen.Context is: bundleresource://106/org/jaxen/Context.class
I'm afraid this is not in the form you'd like to see...
> What about the version of the jelly xml tag? e.g
> org.apache.commons.jelly.tags.xml.SetTag ?
SetTag is in commons-jelly-tags-xml-1.1.jar. Is this the version
you're interested in?
Many thanks, Paul!
Csaba
2011/4/30 Paul Libbrecht <p...@hoplahup.net>:
> Csaba,
>
> this sounds real dark...
>
> Can you try:
>
> <x:parse var="doc">
> <a>
> <b v="1"/>
> <b v="2"/>
> <b v="3"/>
> </a>
> </x:parse>
>
> <x:set select="$doc/a/b" var="x"/>
>
> x is ${x} of class ${x.getClass()} and of size ${size(x)}
>
>
> does it also spin 100%?
>
> Also, could you please try to see the origin a jaxen class? (e.g.
> org.jaxen.Context ?)
> What about the version of the jelly xml tag? e.g
> org.apache.commons.jelly.tags.xml.SetTag ?
>
> thanks in advance
>
> paul
>
>
>
> Le 30 avr. 2011 à 20:16, Csaba Győrffy a écrit :
>
>> If I'm running Paul's script from a standard Java app, DefaultHandler
>> gets loaded from an xml.jar different than the one I mentioned
>> earlier. So, I tried to replace WebSphere's version with the "good"
>> version of xml.jar, but the result is the same: processing of a script
>> with foreach tag hangs, 100% CPU utilization.
>>
>> Origin of DefaultDocument class is the same, no matter if using app
>> server or not. Do you have any idea why it's not working inside the
>> app server?
>>
>> Thanks.
>>
>> Csaba
>>
>> 2011/4/30 Csaba Győrffy <csab...@gmail.com>:
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
