You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Timothy Larson <ti...@yahoo.com> on 2003/11/25 20:32:40 UTC
Build failure because of proxy-firewall
I just downloaded a new snapshot, and now the build fails with this message:
BUILD FAILED
file:C:/cocoon/2.1_20031125111946/cocoon-2.1/build/cocoon-2.1.4-dev/temp/blocks-build.xml:8441:
UnknownHostException. Probable cause: The parser is trying to resolve a dtd from the internet
and no connection exists. You can either connect to the internet during the build, or patch
XConfToolTask.java to ignore DTD declarations when your parser is in use.
My previous snapshot, 2.1_20031120112057, built fine despite the same authenticated
proxy-firewalled network. A quick look through XConfToolTask.java did not enlighten me.
Any clues how to get the builds working again without requiring a network connection?
--Tim Larson
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Re: Build failure because of proxy-firewall
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Timothy Larson dijo:
> I just downloaded a new snapshot, and now the build fails with this
> message:
>
> BUILD FAILED
> file:C:/cocoon/2.1_20031125111946/cocoon-2.1/build/cocoon-2.1.4-dev/temp/blocks-build.xml:8441:
> UnknownHostException. Probable cause: The parser is trying to resolve a
> dtd from the internet
> and no connection exists. You can either connect to the internet during
> the build, or patch
> XConfToolTask.java to ignore DTD declarations when your parser is in use.
>
> My previous snapshot, 2.1_20031120112057, built fine despite the same
> authenticated
> proxy-firewalled network. A quick look through XConfToolTask.java did not
> enlighten me.
> Any clues how to get the builds working again without requiring a network
> connection?
Are you removed the old xerces? I am sure you know about it, but sometimes
we forgot too.
Check for the old xerces on tomcat and also on:
/cocoon-2.1/tools/lib
After this, please do a build.sh clean.
And comment your results on the list :-D
Best Regards,
Antonio Gallardo
Re: Build failure because of proxy-firewall
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Geoff Howard dijo:
> Timothy Larson wrote:
>> I just downloaded a new snapshot, and now the build fails with this
>> message:
>>
>> BUILD FAILED
>> file:C:/cocoon/2.1_20031125111946/cocoon-2.1/build/cocoon-2.1.4-dev/temp/blocks-build.xml:8441:
>> UnknownHostException. Probable cause: The parser is trying to resolve a
>> dtd from the internet
>> and no connection exists. You can either connect to the internet during
>> the build, or patch
>> XConfToolTask.java to ignore DTD declarations when your parser is in
>> use.
>>
>> My previous snapshot, 2.1_20031120112057, built fine despite the same
>> authenticated
>> proxy-firewalled network. A quick look through XConfToolTask.java did
>> not enlighten me.
>> Any clues how to get the builds working again without requiring a
>> network connection?
>
> I wrote that overly verbose message for just such an occasion as this!
> The XConfToolTask (in tools/src/anttasks or used to be) was using a
> parser-specific setting to force it to not resolve dtd references. The
> line is:
>
> builderFactory.setAttribute(
> "http://apache.org/xml/features/nonvalidating/load-external-dtd",
> new Boolean(false));
>
> So, either the latest version of the XML libs committed recently by
> Antonio (this would be Xerces, no?
No, no. Is yes. :-D I updated Xerces to 2.6.0 :-D
It is a interesting bug. I never saw something similar. Note I also do
offline demos and never saw something like that.
>I can never remember which X is
> which!) has changed this behavior, or something in the latest changes to
> support property expansion have broken it.
>
> The first seems way more likely and may be documented at xml.apache.org
> in release notes. Unfortunately, don't have time to look into it myself.
Don't know. :-(
Best Regards,
Antonio Gallardo
Re: Build failure because of proxy-firewall
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Geoff Howard wrote:
> builderFactory.setAttribute(
> "http://apache.org/xml/features/nonvalidating/load-external-dtd",
> new Boolean(false));
Alternatively, try Boolean.FALSE
J.Pietschmann
Re: Xerces 2.6 bug (was Re: Build failure because of proxy-firewall)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 03.12.2003 03:42, Geoff Howard wrote:
> The bugzilla entry and this discussion:
> http://thread.gmane.org/gmane.text.xml.xerces-j.devel/475
> indicate that this is now fixed in xerces cvs.
>
> I tried the solution they suggested as a workaround for 2.6 with no luck
> (though it may be that I don't know my way around XNI).
>
> So, do we
> 1) Ignore the bug until a later version of xerces is released? (the bug
> is that the build fails without an internet connection due to the dtd
> resolving in web.xml)
> 2) Roll back to 2.5? (I assume this would unfix other bugs?)
> 3) Use a dated version of xerces from cvs until their next release.
>
> WDYT?
I tend for 2) as there was no particular need to update to 2.6.
BTW there is also a similar situation for Xalan:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24457.
What to do here?
Joerg
RE: Xerces 2.6 bug (was Re: Build failure because of proxy-firewall)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Let's roll back (Xerces of course) :)
Carsten
> -----Original Message-----
> From: Geoff Howard [mailto:cocoon@leverageweb.com]
> Sent: Wednesday, December 03, 2003 3:42 AM
> To: dev@cocoon.apache.org
> Subject: Xerces 2.6 bug (was Re: Build failure because of
> proxy-firewall)
>
>
> Geoff Howard wrote:
> > Bruno Dumon wrote:
> >
> >> On Wed, 2003-11-26 at 17:47, Timothy Larson wrote:
> >>
> >>> --- Geoff Howard <co...@leverageweb.com> wrote:
> >>>
> >>>> Can someone try rolling back Xerces to prior version to make sure
> >>>> that's the issue? Of course, you'll have to unplug from the network
> >>>> before building or you won't notice the issue. I looked briefly at
> >>>> Xerces' site last night and didn't find any clues this was
> >>>> intentionally changed in the latest release but there were some
> >>>> bugfix descriptions which could point to an accidental new problem.
>
> ...
>
>
> >> If I unplug my network connection, I also get the UnkownHostException.
> >>
> >> I reverted to xercesImpl-2.5.0.jar, left the rest the same, and now it
> >> works for me. So seems like a bug in Xerces to me.
> >
> > I attempted directly using the DOMParser class directly as they
> > recommend in the FAQ with mixed results. I've filed a bug with more
> > details at Xerces bugzilla:
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25043
> >
> > I wasn't able to spend more time digging around or coming up with an
> > isolated test case for them - any takers?
>
> The bugzilla entry and this discussion:
> http://thread.gmane.org/gmane.text.xml.xerces-j.devel/475
> indicate that this is now fixed in xerces cvs.
>
> I tried the solution they suggested as a workaround for 2.6 with no luck
> (though it may be that I don't know my way around XNI).
>
> So, do we
> 1) Ignore the bug until a later version of xerces is released? (the bug
> is that the build fails without an internet connection due to the dtd
> resolving in web.xml)
> 2) Roll back to 2.5? (I assume this would unfix other bugs?)
> 3) Use a dated version of xerces from cvs until their next release.
>
> WDYT?
>
> Geoff
>
Re: Xerces 2.6 bug (was Re: Build failure because of proxy-firewall)
Posted by Geoff Howard <co...@leverageweb.com>.
Vadim Gritsenko wrote:
> Timothy Larson wrote:
>
>> --- Geoff Howard <co...@leverageweb.com> wrote:
>>
>>> So, do we
>>> 1) Ignore the bug until a later version of xerces is released? (the
>>> bug is that the build fails without an internet connection due to the
>>> dtd resolving in web.xml)
>>> 2) Roll back to 2.5? (I assume this would unfix other bugs?)
>>> 3) Use a dated version of xerces from cvs until their next release.
>>>
>>> WDYT?
>
> Either 2 or 3.
>
>> Just for your information, my first test must have been in error,
>> because my setup now works with just the rollback to version 2.5,
>> just like, IIRC, Bruno reported.
>>
>> Unless there are fixes we need in 2.6, I tend toward just rolling
>> back to 2.5 until the next xerces release (option #2).
>> If anyone requires 2.6, then option #3 would be my second choice.
>> Lets not scare off any developers behind firewalls or on trains :)
That's the million lira question - did 2.6 fix other bugs in our cvs?
Anyone? Bueller?
> I had to roll back to 2.5 today... On train... Lucky me had 2.5 in
> another cvs (cocoon 2.2)
Hmmmm, I had thought this should only affect the build when patching
web.xml (or other xml file with an external dtd over the net but I don't
think there are any others ATM).
So were you enabling uploads? The workaround if you're stuck on the
train should be to disable the build-time patch of web.xml and just
patch it by hand like we used to do "back in the day".
Geoff
Re: Xerces 2.6 bug (was Re: Build failure because of proxy-firewall)
Posted by Vadim Gritsenko <va...@verizon.net>.
Timothy Larson wrote:
>--- Geoff Howard <co...@leverageweb.com> wrote:
>
>
>>So, do we
>>1) Ignore the bug until a later version of xerces is released? (the bug
>>is that the build fails without an internet connection due to the dtd
>>resolving in web.xml)
>>2) Roll back to 2.5? (I assume this would unfix other bugs?)
>>3) Use a dated version of xerces from cvs until their next release.
>>
>>WDYT?
>>
>>
Either 2 or 3.
>Just for your information, my first test must have been in error,
>because my setup now works with just the rollback to version 2.5,
>just like, IIRC, Bruno reported.
>
>Unless there are fixes we need in 2.6, I tend toward just rolling
>back to 2.5 until the next xerces release (option #2).
>If anyone requires 2.6, then option #3 would be my second choice.
>Lets not scare off any developers behind firewalls or on trains :)
>
>
I had to roll back to 2.5 today... On train... Lucky me had 2.5 in
another cvs (cocoon 2.2)
Vadim
Re: Xerces 2.6 bug (was Re: Build failure because of proxy-firewall)
Posted by Timothy Larson <ti...@yahoo.com>.
--- Geoff Howard <co...@leverageweb.com> wrote:
> So, do we
> 1) Ignore the bug until a later version of xerces is released? (the bug
> is that the build fails without an internet connection due to the dtd
> resolving in web.xml)
> 2) Roll back to 2.5? (I assume this would unfix other bugs?)
> 3) Use a dated version of xerces from cvs until their next release.
>
> WDYT?
Just for your information, my first test must have been in error,
because my setup now works with just the rollback to version 2.5,
just like, IIRC, Bruno reported.
Unless there are fixes we need in 2.6, I tend toward just rolling
back to 2.5 until the next xerces release (option #2).
If anyone requires 2.6, then option #3 would be my second choice.
Lets not scare off any developers behind firewalls or on trains :)
--Tim Larson
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Xerces 2.6 bug (was Re: Build failure because of proxy-firewall)
Posted by Geoff Howard <co...@leverageweb.com>.
Geoff Howard wrote:
> Bruno Dumon wrote:
>
>> On Wed, 2003-11-26 at 17:47, Timothy Larson wrote:
>>
>>> --- Geoff Howard <co...@leverageweb.com> wrote:
>>>
>>>> Can someone try rolling back Xerces to prior version to make sure
>>>> that's the issue? Of course, you'll have to unplug from the network
>>>> before building or you won't notice the issue. I looked briefly at
>>>> Xerces' site last night and didn't find any clues this was
>>>> intentionally changed in the latest release but there were some
>>>> bugfix descriptions which could point to an accidental new problem.
...
>> If I unplug my network connection, I also get the UnkownHostException.
>>
>> I reverted to xercesImpl-2.5.0.jar, left the rest the same, and now it
>> works for me. So seems like a bug in Xerces to me.
>
> I attempted directly using the DOMParser class directly as they
> recommend in the FAQ with mixed results. I've filed a bug with more
> details at Xerces bugzilla:
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25043
>
> I wasn't able to spend more time digging around or coming up with an
> isolated test case for them - any takers?
The bugzilla entry and this discussion:
http://thread.gmane.org/gmane.text.xml.xerces-j.devel/475
indicate that this is now fixed in xerces cvs.
I tried the solution they suggested as a workaround for 2.6 with no luck
(though it may be that I don't know my way around XNI).
So, do we
1) Ignore the bug until a later version of xerces is released? (the bug
is that the build fails without an internet connection due to the dtd
resolving in web.xml)
2) Roll back to 2.5? (I assume this would unfix other bugs?)
3) Use a dated version of xerces from cvs until their next release.
WDYT?
Geoff
Re: Build failure because of proxy-firewall
Posted by Geoff Howard <co...@leverageweb.com>.
Bruno Dumon wrote:
> On Wed, 2003-11-26 at 17:47, Timothy Larson wrote:
>
>>--- Geoff Howard <co...@leverageweb.com> wrote:
>>
>>>Can someone try rolling back Xerces to prior version to make sure that's
>>>the issue? Of course, you'll have to unplug from the network before
>>>building or you won't notice the issue. I looked briefly at Xerces'
>>>site last night and didn't find any clues this was intentionally changed
>>>in the latest release but there were some bugfix descriptions which
>>>could point to an accidental new problem.
>>
>>I retrieved old files via viewcvs:
>> cocoon\2.1_20031125111946\cocoon-2.1\lib\endorsed\xercesImpl-2.5.0.jar (Rev 1.1)
>> cocoon\2.1_20031125111946\cocoon-2.1\lib\endorsed\xml-apis.jar (Rev 1.4)
>> cocoon\2.1_20031125111946\cocoon-2.1\tools\anttasks\XConfToolTask.java (Rev 1.8)
>>and prepared for a clean build by deleting:
>> cocoon\2.1_20031125111946\cocoon-2.1\build\cocoon-2.1.4-dev
>> cocoon\2.1_20031125111946\cocoon-2.1\build\webapp
>> cocoon\2.1_20031125111946\cocoon-2.1\lib\endorsed\xercesImpl-2.6.0.jar
>> cocoon\2.1_20031125111946\cocoon-2.1\tools\anttasks\ManifestToolTask.class
>> cocoon\2.1_20031125111946\cocoon-2.1\tools\anttasks\XConfToolTask.class
>>but the clean build still produced the same UnknownHostException.
>>
>>Aaaahhhh!!!!
>
>
> If I unplug my network connection, I also get the UnkownHostException.
>
> I reverted to xercesImpl-2.5.0.jar, left the rest the same, and now it
> works for me. So seems like a bug in Xerces to me.
I attempted directly using the DOMParser class directly as they
recommend in the FAQ with mixed results. I've filed a bug with more
details at Xerces bugzilla:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25043
I wasn't able to spend more time digging around or coming up with an
isolated test case for them - any takers?
Geoff
Re: Build failure because of proxy-firewall
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-11-26 at 17:47, Timothy Larson wrote:
> --- Geoff Howard <co...@leverageweb.com> wrote:
> > Can someone try rolling back Xerces to prior version to make sure that's
> > the issue? Of course, you'll have to unplug from the network before
> > building or you won't notice the issue. I looked briefly at Xerces'
> > site last night and didn't find any clues this was intentionally changed
> > in the latest release but there were some bugfix descriptions which
> > could point to an accidental new problem.
>
> I retrieved old files via viewcvs:
> cocoon\2.1_20031125111946\cocoon-2.1\lib\endorsed\xercesImpl-2.5.0.jar (Rev 1.1)
> cocoon\2.1_20031125111946\cocoon-2.1\lib\endorsed\xml-apis.jar (Rev 1.4)
> cocoon\2.1_20031125111946\cocoon-2.1\tools\anttasks\XConfToolTask.java (Rev 1.8)
> and prepared for a clean build by deleting:
> cocoon\2.1_20031125111946\cocoon-2.1\build\cocoon-2.1.4-dev
> cocoon\2.1_20031125111946\cocoon-2.1\build\webapp
> cocoon\2.1_20031125111946\cocoon-2.1\lib\endorsed\xercesImpl-2.6.0.jar
> cocoon\2.1_20031125111946\cocoon-2.1\tools\anttasks\ManifestToolTask.class
> cocoon\2.1_20031125111946\cocoon-2.1\tools\anttasks\XConfToolTask.class
> but the clean build still produced the same UnknownHostException.
>
> Aaaahhhh!!!!
If I unplug my network connection, I also get the UnkownHostException.
I reverted to xercesImpl-2.5.0.jar, left the rest the same, and now it
works for me. So seems like a bug in Xerces to me.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Build failure because of proxy-firewall
Posted by Timothy Larson <ti...@yahoo.com>.
--- Geoff Howard <co...@leverageweb.com> wrote:
> Can someone try rolling back Xerces to prior version to make sure that's
> the issue? Of course, you'll have to unplug from the network before
> building or you won't notice the issue. I looked briefly at Xerces'
> site last night and didn't find any clues this was intentionally changed
> in the latest release but there were some bugfix descriptions which
> could point to an accidental new problem.
I retrieved old files via viewcvs:
cocoon\2.1_20031125111946\cocoon-2.1\lib\endorsed\xercesImpl-2.5.0.jar (Rev 1.1)
cocoon\2.1_20031125111946\cocoon-2.1\lib\endorsed\xml-apis.jar (Rev 1.4)
cocoon\2.1_20031125111946\cocoon-2.1\tools\anttasks\XConfToolTask.java (Rev 1.8)
and prepared for a clean build by deleting:
cocoon\2.1_20031125111946\cocoon-2.1\build\cocoon-2.1.4-dev
cocoon\2.1_20031125111946\cocoon-2.1\build\webapp
cocoon\2.1_20031125111946\cocoon-2.1\lib\endorsed\xercesImpl-2.6.0.jar
cocoon\2.1_20031125111946\cocoon-2.1\tools\anttasks\ManifestToolTask.class
cocoon\2.1_20031125111946\cocoon-2.1\tools\anttasks\XConfToolTask.class
but the clean build still produced the same UnknownHostException.
Aaaahhhh!!!!
--Tim Larson
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Re: Build failure because of proxy-firewall
Posted by Geoff Howard <co...@leverageweb.com>.
David Crossley wrote:
> Geoff Howard wrote:
>
>>Timothy Larson wrote:
>>
>>>I just downloaded a new snapshot, and now the build fails with this message:
>>>
>>>BUILD FAILED
>>>file:C:/cocoon/2.1_20031125111946/cocoon-2.1/build/cocoon-2.1.4-dev/temp/blocks-build.xml:8441:
>>>UnknownHostException. Probable cause: The parser is trying to resolve a dtd from the internet
>>>and no connection exists. You can either connect to the internet during the build, or patch
>>>XConfToolTask.java to ignore DTD declarations when your parser is in use.
>>>
>>>My previous snapshot, 2.1_20031120112057, built fine despite the same authenticated
>>>proxy-firewalled network. A quick look through XConfToolTask.java did not enlighten me.
>>>Any clues how to get the builds working again without requiring a network connection?
>>
>>I wrote that overly verbose message for just such an occasion as this!
>> The XConfToolTask (in tools/src/anttasks or used to be) was using a
>>parser-specific setting to force it to not resolve dtd references. The
>>line is:
>>
>>builderFactory.setAttribute(
>>"http://apache.org/xml/features/nonvalidating/load-external-dtd",
>> new Boolean(false));
>>
>>So, either the latest version of the XML libs committed recently by
>>Antonio (this would be Xerces, no? I can never remember which X is
>>which!) has changed this behavior, or something in the latest changes to
>>support property expansion have broken it.
>>
>>The first seems way more likely and may be documented at xml.apache.org
>>in release notes. Unfortunately, don't have time to look into it myself.
>
>
> Why would XConfToolTask be trying to go onto the network anyway?
> What DTD is it trying to get? Oh i see, it is trying to deal with
> web.xml which points to a DTD at Sun.
>
> There is an attempt to use XMLCatalog in XConfToolTask. Perhaps we
> just need to add some configuration for a local copy. I vaguely
> recall investigating this before, but i think that i got frightened
> by Sun's conditions in the DTD license (the "not without written
> authorisation" thing).
http://marc.theaimsgroup.com/?t=105357989100002&r=1&w=2 is where we
discussed the issues. I think (though I only scanned the archive this
time) that we decided there _probably_ was a licensing issue (I could
swear someone eventually chimed in more definitively but can't find it
ATM) but that configuring to not resolve external DTD was enough for
this use anyway. Now that's broken but it isn't clear why yet so
discussing another solution is probably premature.
Can someone try rolling back Xerces to prior version to make sure that's
the issue? Of course, you'll have to unplug from the network before
building or you won't notice the issue. I looked briefly at Xerces'
site last night and didn't find any clues this was intentionally changed
in the latest release but there were some bugfix descriptions which
could point to an accidental new problem.
Geoff
Re: Build failure because of proxy-firewall
Posted by David Crossley <cr...@indexgeo.com.au>.
Geoff Howard wrote:
> Timothy Larson wrote:
> > I just downloaded a new snapshot, and now the build fails with this message:
> >
> > BUILD FAILED
> > file:C:/cocoon/2.1_20031125111946/cocoon-2.1/build/cocoon-2.1.4-dev/temp/blocks-build.xml:8441:
> > UnknownHostException. Probable cause: The parser is trying to resolve a dtd from the internet
> > and no connection exists. You can either connect to the internet during the build, or patch
> > XConfToolTask.java to ignore DTD declarations when your parser is in use.
> >
> > My previous snapshot, 2.1_20031120112057, built fine despite the same authenticated
> > proxy-firewalled network. A quick look through XConfToolTask.java did not enlighten me.
> > Any clues how to get the builds working again without requiring a network connection?
>
> I wrote that overly verbose message for just such an occasion as this!
> The XConfToolTask (in tools/src/anttasks or used to be) was using a
> parser-specific setting to force it to not resolve dtd references. The
> line is:
>
> builderFactory.setAttribute(
> "http://apache.org/xml/features/nonvalidating/load-external-dtd",
> new Boolean(false));
>
> So, either the latest version of the XML libs committed recently by
> Antonio (this would be Xerces, no? I can never remember which X is
> which!) has changed this behavior, or something in the latest changes to
> support property expansion have broken it.
>
> The first seems way more likely and may be documented at xml.apache.org
> in release notes. Unfortunately, don't have time to look into it myself.
Why would XConfToolTask be trying to go onto the network anyway?
What DTD is it trying to get? Oh i see, it is trying to deal with
web.xml which points to a DTD at Sun.
There is an attempt to use XMLCatalog in XConfToolTask. Perhaps we
just need to add some configuration for a local copy. I vaguely
recall investigating this before, but i think that i got frightened
by Sun's conditions in the DTD license (the "not without written
authorisation" thing).
--David
Re: Build failure because of proxy-firewall
Posted by Geoff Howard <co...@leverageweb.com>.
Timothy Larson wrote:
> I just downloaded a new snapshot, and now the build fails with this message:
>
> BUILD FAILED
> file:C:/cocoon/2.1_20031125111946/cocoon-2.1/build/cocoon-2.1.4-dev/temp/blocks-build.xml:8441:
> UnknownHostException. Probable cause: The parser is trying to resolve a dtd from the internet
> and no connection exists. You can either connect to the internet during the build, or patch
> XConfToolTask.java to ignore DTD declarations when your parser is in use.
>
> My previous snapshot, 2.1_20031120112057, built fine despite the same authenticated
> proxy-firewalled network. A quick look through XConfToolTask.java did not enlighten me.
> Any clues how to get the builds working again without requiring a network connection?
I wrote that overly verbose message for just such an occasion as this!
The XConfToolTask (in tools/src/anttasks or used to be) was using a
parser-specific setting to force it to not resolve dtd references. The
line is:
builderFactory.setAttribute(
"http://apache.org/xml/features/nonvalidating/load-external-dtd",
new Boolean(false));
So, either the latest version of the XML libs committed recently by
Antonio (this would be Xerces, no? I can never remember which X is
which!) has changed this behavior, or something in the latest changes to
support property expansion have broken it.
The first seems way more likely and may be documented at xml.apache.org
in release notes. Unfortunately, don't have time to look into it myself.
Geoff