ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hari Krishna Dara" <harid...@gmail.com>
Subject Re: FileSet inside MacroDef causing ClassCastException
Date Wed, 23 Aug 2006 21:06:19 GMT
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 <haridara@gmail.com> wrote:
> > From: Mathieu Champlon <m.champlon@free.fr>
> > 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="${@{componentName}NeedsPatchTmp}"
> > > 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message