This is a different problem to MATs.
This problem is due to the resolution of references.
The build script can be reduced to:
<project>
<macrodef name="my-macrodef">
<sequential>
<fileset id="fs" dir="."/>
</sequential>
</macrodef>
<script language="beanshell"/>
<my-macrodef/>
</project>
When the script task is executed, it converts all
ant references to script variables (yuck). Ant references
are set at parse time (double yuck) and so the "fs"
reference will be resolved, this resolution converts the UnknownElement
to a "real" object (triple yuck) which causes the bug.
The last behaviour could be modified - but it is tricky
code and it is difficult to modify without causing more bugs
and backward compatibly problems.
Peter
On 8/23/06, Hari Krishna Dara <[EMAIL PROTECTED]> wrote:
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]
