You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leszek Gawron <lg...@mobilebox.pl> on 2005/01/21 15:58:23 UTC

dynamic macro junit test [was: jx : cocoon.request object ??]

Daniel Fagerstrom wrote:
> Your (and others) work is needed, so that we can make the refactored 
> JXTG stable enough for production use soon.
I've been trying to trace down the problem with non working dynamic 
macro test case. Funny thing is the same exception 
(NumberFormatException) gets thrown for "old" JXTG.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Re: dynamic macro junit test [was: jx : cocoon.request object ??]

Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
> 
>> Daniel Fagerstrom wrote:
>>
>>> Leszek Gawron wrote:
>>>
>>>> Daniel Fagerstrom wrote:
>>>>
>>>>> Leszek Gawron wrote:
>>>>>
>>>>>> Daniel Fagerstrom wrote:
>>>>>>
>>>>>>> Your (and others) work is needed, so that we can make the 
>>>>>>> refactored JXTG stable enough for production use soon.
>>>>>>
>>>>>>
>>>>>> I've been trying to trace down the problem with non working 
>>>>>> dynamic macro test case. Funny thing is the same exception 
>>>>>> (NumberFormatException) gets thrown for "old" JXTG.
>>>>>
>>>>>
>>>>> That at least means that I haven't broke it ;) It might even be 
>>>>> good that it doesn't work as that could mean that nobody use it and 
>>>>> it would be easier to deprecate and replace with something better.
>>>>
>>>>
>>>> I am using it in my projects - and it works! This is one of most 
>>>> common technique of mine to write more advanced macros. Magic? I 
>>>> guess :)
>>>
>>>
>>> Ok, then it would be good if you wrote a test case that works in the 
>>> original JXTG so that we can check that it still work in the 
>>> refactored version. I just took the example from the documentation 
>>> and made a test case from it.
>>
>>
>> I checked it - works only when the pipeline is invoked from flow. 
>> Still I have no idea how that affects parsing ${tags.example} expression.
> 
> 
> Neither have I, the test case only acceses variables that are defined in 
> the current context, so how what it got (or not got) from flow can 
> affect it is unclear to me.
> 
> Just to avoid missunderstandings, exactly what have you tested? Original 
> JXTG and refactored JXTG and for both: with and whithout flow?
Yes. Both JXTG and new JXTG work when called from flowscript and fail 
from standalone pipeline.

> 
> The problem (or at least one of them), seem to be connected to the 
> hashmap. I checked in a new test case: jxSet, that works for a simple 
> assignement but not for a hashmap.
Fine. I'll try to compare the results with previous versions of jxpath 
and jexl.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Re: dynamic macro junit test [was: jx : cocoon.request object ??]

Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
>> Leszek Gawron wrote:
>>> Daniel Fagerstrom wrote:
>>>> Leszek Gawron wrote:
>>>>> Daniel Fagerstrom wrote:
>>>>>
>>>>>> Your (and others) work is needed, so that we can make the 
>>>>>> refactored JXTG stable enough for production use soon.
>>>>>
>>>>> I've been trying to trace down the problem with non working dynamic 
>>>>> macro test case. Funny thing is the same exception 
>>>>> (NumberFormatException) gets thrown for "old" JXTG.
>>>>
>>>> That at least means that I haven't broke it ;) It might even be good 
>>>> that it doesn't work as that could mean that nobody use it and it 
>>>> would be easier to deprecate and replace with something better.
>>>
>>> I am using it in my projects - and it works! This is one of most 
>>> common technique of mine to write more advanced macros. Magic? I 
>>> guess :)
>>
>> Ok, then it would be good if you wrote a test case that works in the 
>> original JXTG so that we can check that it still work in the 
>> refactored version. I just took the example from the documentation and 
>> made a test case from it.
> 
> I checked it - works only when the pipeline is invoked from flow. Still 
> I have no idea how that affects parsing ${tags.example} expression.

Neither have I, the test case only acceses variables that are defined in 
the current context, so how what it got (or not got) from flow can 
affect it is unclear to me.

Just to avoid missunderstandings, exactly what have you tested? Original 
JXTG and refactored JXTG and for both: with and whithout flow?

The problem (or at least one of them), seem to be connected to the 
hashmap. I checked in a new test case: jxSet, that works for a simple 
assignement but not for a hashmap.

/Daniel

Re: dynamic macro junit test [was: jx : cocoon.request object ??]

Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
> 
>> Daniel Fagerstrom wrote:
>>
>>> Leszek Gawron wrote:
>>>
>>>> Daniel Fagerstrom wrote:
>>>>
>>>>> Your (and others) work is needed, so that we can make the 
>>>>> refactored JXTG stable enough for production use soon.
>>>>
>>>>
>>>> I've been trying to trace down the problem with non working dynamic 
>>>> macro test case. Funny thing is the same exception 
>>>> (NumberFormatException) gets thrown for "old" JXTG.
>>>
>>>
>>> That at least means that I haven't broke it ;) It might even be good 
>>> that it doesn't work as that could mean that nobody use it and it 
>>> would be easier to deprecate and replace with something better.
>>
>>
>> I am using it in my projects - and it works! This is one of most 
>> common technique of mine to write more advanced macros. Magic? I guess :)
> 
> 
> Ok, then it would be good if you wrote a test case that works in the 
> original JXTG so that we can check that it still work in the refactored 
> version. I just took the example from the documentation and made a test 
> case from it.

I checked it - works only when the pipeline is invoked from flow. Still 
I have no idea how that affects parsing ${tags.example} expression.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Re: dynamic macro junit test [was: jx : cocoon.request object ??]

Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
> 
>> Leszek Gawron wrote:
>>
>>> Daniel Fagerstrom wrote:
>>>
>>>> Your (and others) work is needed, so that we can make the refactored 
>>>> JXTG stable enough for production use soon.
>>>
>>> I've been trying to trace down the problem with non working dynamic 
>>> macro test case. Funny thing is the same exception 
>>> (NumberFormatException) gets thrown for "old" JXTG.
>>
>> That at least means that I haven't broke it ;) It might even be good 
>> that it doesn't work as that could mean that nobody use it and it 
>> would be easier to deprecate and replace with something better.
> 
> I am using it in my projects - and it works! This is one of most common 
> technique of mine to write more advanced macros. Magic? I guess :)

Ok, then it would be good if you wrote a test case that works in the 
original JXTG so that we can check that it still work in the refactored 
version. I just took the example from the documentation and made a test 
case from it.

> Still we can kill it completely when I introduce jx:call 
> macro="something" because this construct is functionally equivalent and 
> more powerful.

Ok.

/Daniel


Re: dynamic macro junit test [was: jx : cocoon.request object ??]

Posted by Leszek Gawron <lg...@mobilebox.pl>.
Daniel Fagerstrom wrote:
> Leszek Gawron wrote:
> 
>> Daniel Fagerstrom wrote:
>>
>>> Your (and others) work is needed, so that we can make the refactored 
>>> JXTG stable enough for production use soon.
>>
>>
>> I've been trying to trace down the problem with non working dynamic 
>> macro test case. Funny thing is the same exception 
>> (NumberFormatException) gets thrown for "old" JXTG.
> 
> 
> That at least means that I haven't broke it ;) It might even be good 
> that it doesn't work as that could mean that nobody use it and it would 
> be easier to deprecate and replace with something better.
I am using it in my projects - and it works! This is one of most common 
technique of mine to write more advanced macros. Magic? I guess :)

Still we can kill it completely when I introduce jx:call 
macro="something" because this construct is functionally equivalent and 
more powerful.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Re: dynamic macro junit test [was: jx : cocoon.request object ??]

Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Leszek Gawron wrote:
> Daniel Fagerstrom wrote:
> 
>> Your (and others) work is needed, so that we can make the refactored 
>> JXTG stable enough for production use soon.
> 
> I've been trying to trace down the problem with non working dynamic 
> macro test case. Funny thing is the same exception 
> (NumberFormatException) gets thrown for "old" JXTG.

That at least means that I haven't broke it ;) It might even be good 
that it doesn't work as that could mean that nobody use it and it would 
be easier to deprecate and replace with something better.

/Daniel