Here is a simpler test case, that removes some ambiguities. As you can
see the content of the script task doesn't matter.
<?xml version="1.0"?>
<project name="nested_macrodef_generates_class_cast_exception_modified"
default="test">
<macrodef name="patchif">
<sequential>
<echo message="I am patchif macro"/>
<script language="beanshell"><![CDATA[
]]></script>
</sequential>
</macrodef>
<macrodef name="my-macrodef">
<element name="elements"/>
<element name="selection"/>
<sequential>
<fileset id="fs" dir=".">
<selection/>
</fileset>
<elements/>
</sequential>
</macrodef>
<target name="test">
<patchif/>
<my-macrodef>
<elements>
<echo>Test !!</echo>
</elements>
<selection>
<filename name="xxx"/>
</selection>
</my-macrodef>
</target>
</project>
On 8/23/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
> From: Mathieu Champlon <[EMAIL PROTECTED]>
> To: Ant Developers List <dev@ant.apache.org>
> Date: Wed, 23 Aug 2006 14:50:20 +0900
> Subject: Re: FileSet inside MacroDef causing ClassCastException
> Hello !
>
> Hari Krishna Dara a écrit :
> > Can anyone provide any help in working around or fixing this problem?
>
> It looks like the same bug as
> http://issues.apache.org/bugzilla/show_bug.cgi?id=40238 ?
>
> > Here is the macro that causes trouble (I stripped the sequence to the
> > least that causes theis problem, but as I said before, I couldn't copy
> > this into a standalone build file and reproduce the exception):
> >
> > <macrodef name="patchifmatches">
> > <attribute name="source"/>
> > <!-- See "target" on patchif -->
> > <attribute name="target"/>
> > <attribute name="windows" default="true"/>
> > <attribute name="solaris" default="true"/>
> > <element name="selection" implicit="true"/>
> > <sequential>
> > <fileset id="patchfileset" dir="${branch.path}">
> > <patternset refid="patch.filelist"/>
> > <selection/>
> > </fileset>
> > </sequential>
> > </macrodef>
> >
> > Here is the macro that is part of the same build file and works fine:
> >
> > <macrodef name="checkIfComponentNeedsPatch">
> > <attribute name="componentName"/>
> > <element name="selection" implicit="true"/>
> > <sequential>
> > <!-- FIXME: How do I suppress the "override" warning
> > message this generates -->
> > <fileset id="patchfileset" dir="${branch.path}">
> > <patternset refid="patch.filelist"/>
> > <selection/>
> > </fileset>
> > <pathconvert pathsep=" "
> > property="@{componentName}NeedsPatchTmp"
> > refid="patchfileset"/>
> > <condition property="@{componentName}NeedsPatch">
> > <not>
> > <equals arg1="[EMAIL PROTECTED]"
> > arg2=""/>
> > </not>
> > </condition>
> > </sequential>
> > </macrodef>
> How are your macro called ? With what 'selection' ?
> How many times each ? In which order ?
> What happens when you remove the call to the 'working' one ? (I suspect
> it 'fixes' the other :p)
>
> I'm not really surprised by the fact that it works fine when you copy
> your macros to a new build file, I had quite a lot of fun trying to
> reproduce the bug for the issue :)
> Actually what happens is that the same element is used either in several
> macros or several times in the same macro. Then as it gets resolved (and
> so is not an unknown element anymore) upon first use, it is no longer an
> UnknownElement for the remaining calls...
> I don't know if this makes sense, but anyway try and apply the patch and
> see if it fixes this issue for you ?
>
> MAT.
I tried the patch suggested in the bug report on 1.6.2, but that
didn't solve the problem. So I applied the patch to 1.6.5 version, but
still I got the same exception. However, I was able to verify that the
patch fixes the testcase that you attached (by running before and
after applying the patch).
Just like you guessed, if I comment the lines that are working, the
next two calls to this macro including the one that was failing
before, go through fine. This probably indicates that the problem you
reported and this are related, but there is still another case that is
not taken care of?
Based upon your test case, and more trial and error of carefully
commenting parts of the code, I narrowed down the macrodef's that are
causing this problem. I am pasting a reproducible test case below, but
it requires BeanShell/BSF jar files to be present in the classpath/ant
lib directory (bsf.jar, bsh-2.0b4.jar and bsh-bsf-2.0b4.jar). Can
anyone please take a look at this test case and give any guidance on
how to find and fix the problem?
PS: If anyone wants, I can send the above 3 jar files by email to make
it easier for you to run the below testcase.
Thank you,
Hari
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
