You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by jo...@apache.org on 2007/11/23 04:49:59 UTC
svn commit: r597535 - in
/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src:
main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java
test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
Author: joerg
Date: Thu Nov 22 19:49:58 2007
New Revision: 597535
URL: http://svn.apache.org/viewvc?rev=597535&view=rev
Log:
Fix FlowJXPathSelectionList test-case in a different way:
Since it was the test case that's broken, not our code, fix the issue in the test case.
Modified:
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java
cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
Modified: cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java
URL: http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java?rev=597535&r1=597534&r2=597535&view=diff
==============================================================================
--- cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java (original)
+++ cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java Thu Nov 22 19:49:58 2007
@@ -23,7 +23,6 @@
import org.apache.cocoon.forms.FormsConstants;
import org.apache.cocoon.forms.util.I18nMessage;
import org.apache.cocoon.processing.ProcessInfoProvider;
-import org.apache.cocoon.xml.AttributeTypes;
import org.apache.cocoon.xml.AttributesImpl;
import org.apache.cocoon.xml.XMLUtils;
import org.apache.commons.jxpath.JXPathContext;
@@ -117,11 +116,7 @@
}
// Start the selection-list
- //FIXME: I added attribute for namespace declaration because it would not be serialized otherwise
- //why it's not printed even if we specify necessary information in startElement() method? (GK)
- AttributesImpl attrs = new AttributesImpl();
- attrs.addAttribute("", FormsConstants.INSTANCE_PREFIX, "xmlns:" + FormsConstants.INSTANCE_PREFIX, AttributeTypes.CDATA, FormsConstants.INSTANCE_NS);
- contentHandler.startElement(FormsConstants.INSTANCE_NS, SELECTION_LIST_EL, FormsConstants.INSTANCE_PREFIX_COLON + SELECTION_LIST_EL, attrs);
+ contentHandler.startElement(FormsConstants.INSTANCE_NS, SELECTION_LIST_EL, FormsConstants.INSTANCE_PREFIX_COLON + SELECTION_LIST_EL, XMLUtils.EMPTY_ATTRIBUTES);
if( this.nullable ) {
final AttributesImpl voidAttrs = new AttributesImpl( );
voidAttrs.addCDATAAttribute( "value", "" );
Modified: cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
URL: http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java?rev=597535&r1=597534&r2=597535&view=diff
==============================================================================
--- cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java (original)
+++ cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java Thu Nov 22 19:49:58 2007
@@ -68,8 +68,10 @@
Source expectedSource = new ResourceSource("resource://org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.dest.xml");
Document expected = this.parser.parse(expectedSource.getInputStream());
Document destDocument = dest.getDocument();
- assertEqual("Test if generated list matches expected",
- expected, destDocument);
+ // FIXME: Why is the namespace declaration available as attribute on the expected document?
+ // That's the reason why we have to add it to destDocument as well.
+ destDocument.getDocumentElement().setAttribute("xmlns:" + FormsConstants.INSTANCE_PREFIX, FormsConstants.INSTANCE_NS);
+ assertEqual("Test if generated list matches expected", expected, destDocument);
}
/**
@@ -94,8 +96,10 @@
Source expectedSource = new ResourceSource("resource://org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCaseWithNull.dest.xml");
Document expected = this.parser.parse(expectedSource.getInputStream());
Document destDocument = dest.getDocument();
- assertEqual("Test if generated list matches expected",
- expected, destDocument);
+ // FIXME: Why is the namespace declaration available as attribute on the expected document?
+ // That's the reason why we have to add it to destDocument as well.
+ destDocument.getDocumentElement().setAttribute("xmlns:" + FormsConstants.INSTANCE_PREFIX, FormsConstants.INSTANCE_NS);
+ assertEqual("Test if generated list matches expected", expected, destDocument);
}
public static class TestBean {
Re: Broken test-cases due to missing namespace declarations
Posted by Antonio Gallardo <ag...@agssa.net>.
Grzegorz Kossakowski escribió:
> Joerg Heinicke pisze:
>
>> It does not just wrap Xalan's DOMBuilder. It kind of does the same but
>> has a different approach: Both build a DOM from SAX events but while
>> Xalan's does it directly Cocoon's DOMBuilder utilizes a
>> TransformerHandler and a DOMResult for it. Additionally listening
>> capability is added and XMLPipe implemented. Also Xalan's DOMBuilder is
>> more a internal class, it's not part of public API. It's a public class
>> but unless you want to tie your code to Xalan there is no way to
>> instantiate the class. That's what you usually do using
>> SAXTransformerFactory as Cocoon's DOMBuilder does or
>> DocumentBuilderFactory. The names matches more or less by coincidence.
>>
>
> Thanks for explanation Joerg! Even I play with Cocoon for some time I don't know low-level details
> of Xalan but I think it only proves value of Cocoon that hides all these nasty details. :)
>
>
>
>> Our code is not really broken. Usually we call startPrefixMapping() in
>> startDocument() methods of transformers or something like this. It's
>> only broken for the test cases since we just have a look at the
>> "component" to test without its "framework". From a component POV adding
>> start/endPrefixMapping() is the "correct" solution to encapsulate it.
>> The question I asked was only if these components will ever run outside
>> of their current framework. Personally I prefer the "correct" approach
>> as well.
>>
>
> I see. Then, agreed with you. Anyway, I have taken effort of tweaking our "components" and
> test-cases so all of them pass now. You probably already noticed attached patches to COCOON-2155 issue.
> I would like to see them committed as soon as we can upgrade to Xalan 2.7.1.
>
>
>> I have no idea what the different ways mean in regard of getting things
>> done correctly and as fast as possible. I only got the jar from
>> Antonio's commit to 2.1 and put it into my local repository by copying
>> 2.7.0's POM.
>>
>
> So the question should be addressed to Antonio: Where the jar of Xalan you committed into 2.1.x
> branch comes from? :)
>
Hi Gregorz,
Sorry for the delayed reply. Xalan as many other jars has different ways
to build it. The one we use in cocoon is one of them without including
indise the jar some of the other endorsed libraries.
Best Regards,
Antonio Gallardo.
Re: Broken test-cases due to missing namespace declarations
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Joerg Heinicke pisze:
>
> It does not just wrap Xalan's DOMBuilder. It kind of does the same but
> has a different approach: Both build a DOM from SAX events but while
> Xalan's does it directly Cocoon's DOMBuilder utilizes a
> TransformerHandler and a DOMResult for it. Additionally listening
> capability is added and XMLPipe implemented. Also Xalan's DOMBuilder is
> more a internal class, it's not part of public API. It's a public class
> but unless you want to tie your code to Xalan there is no way to
> instantiate the class. That's what you usually do using
> SAXTransformerFactory as Cocoon's DOMBuilder does or
> DocumentBuilderFactory. The names matches more or less by coincidence.
Thanks for explanation Joerg! Even I play with Cocoon for some time I don't know low-level details
of Xalan but I think it only proves value of Cocoon that hides all these nasty details. :)
> Our code is not really broken. Usually we call startPrefixMapping() in
> startDocument() methods of transformers or something like this. It's
> only broken for the test cases since we just have a look at the
> "component" to test without its "framework". From a component POV adding
> start/endPrefixMapping() is the "correct" solution to encapsulate it.
> The question I asked was only if these components will ever run outside
> of their current framework. Personally I prefer the "correct" approach
> as well.
I see. Then, agreed with you. Anyway, I have taken effort of tweaking our "components" and
test-cases so all of them pass now. You probably already noticed attached patches to COCOON-2155 issue.
I would like to see them committed as soon as we can upgrade to Xalan 2.7.1.
>
> I have no idea what the different ways mean in regard of getting things
> done correctly and as fast as possible. I only got the jar from
> Antonio's commit to 2.1 and put it into my local repository by copying
> 2.7.0's POM.
So the question should be addressed to Antonio: Where the jar of Xalan you committed into 2.1.x
branch comes from? :)
--
Grzegorz Kossakowski
Re: Broken test-cases due to missing namespace declarations
Posted by Joerg Heinicke <jo...@gmx.de>.
On 27.12.2007 15:00 Uhr, Grzegorz Kossakowski wrote:
>> Second, that's not quite correct. Xalan 2.7.1 fixes the issue. Our
>> DOMBuilder is only a wrapper. It does not replace the Xalan DOMBuilder
>> at all.
>
> I'm not sure if it's only me but this wrapper is not as simple as I would like to see it. From just
> look at the code of our wrapper it is quite hard to figure out that it uses DOMBuilder from Xalan.
It does not just wrap Xalan's DOMBuilder. It kind of does the same but
has a different approach: Both build a DOM from SAX events but while
Xalan's does it directly Cocoon's DOMBuilder utilizes a
TransformerHandler and a DOMResult for it. Additionally listening
capability is added and XMLPipe implemented. Also Xalan's DOMBuilder is
more a internal class, it's not part of public API. It's a public class
but unless you want to tie your code to Xalan there is no way to
instantiate the class. That's what you usually do using
SAXTransformerFactory as Cocoon's DOMBuilder does or
DocumentBuilderFactory. The names matches more or less by coincidence.
>> The fix for XALANJ-2091 is triggered by startPrefixMapping(). With
>> FlowJXPathSelectionList.generateSaxFragment() as in the test case
>> without the actual CForms framework code startPrefixMapping() is never
>> called. After I added startPrefixMapping() at the very beginning of
>> FlowJXPathSelectionList.generateSaxFragment() and endPrefixMapping() at
>> the end of it the test passed without the explicit
>> removal of the namespace attribute.
>> The question is if we really want to change all places where this
>> applies and add start/endPrefixMapping(). In theory that's the correct
>> way to do it. Another possibility to fix the tests would be to serialize
>> the XML from the actual test run and reparse it in the same way as the
>> documents we compare to.
>
> I opt for fixing our code by adding start/endPrefixMapping() as it seems to be the cleanest possible
> solution. Apart from that I think that SAX spec. enfornces on us to use these methods if we want to
> produce proper (representing well-formed XML) stream of SAX events.
Our code is not really broken. Usually we call startPrefixMapping() in
startDocument() methods of transformers or something like this. It's
only broken for the test cases since we just have a look at the
"component" to test without its "framework". From a component POV adding
start/endPrefixMapping() is the "correct" solution to encapsulate it.
The question I asked was only if these components will ever run outside
of their current framework. Personally I prefer the "correct" approach
as well.
> The only problem I can see now is that Xalan 2.7.1 is _not_ available on Maven central repository.
> Do you have an idea how to quickly add it to repository? Should we ask Xalan people to upload it or
> should we go for standard procedure (creating issue in Maven jira and attaching artifacts)?
I have no idea what the different ways mean in regard of getting things
done correctly and as fast as possible. I only got the jar from
Antonio's commit to 2.1 and put it into my local repository by copying
2.7.0's POM.
Joerg
Broken test-cases due to missing namespace declarations (was: Re:
svn commit: r597535 - in /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src:
main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java)
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Joerg Heinicke pisze:
> Grek, thanks for your work on this. I figured out the missing pieces.
Great, thanks! :)
> First, I did not know that DOM is slightly different than the theory of
> XML.
Nor I did at the firs time. ;)
> Second, that's not quite correct. Xalan 2.7.1 fixes the issue. Our
> DOMBuilder is only a wrapper. It does not replace the Xalan DOMBuilder
> at all.
I'm not sure if it's only me but this wrapper is not as simple as I would like to see it. From just
look at the code of our wrapper it is quite hard to figure out that it uses DOMBuilder from Xalan.
Isn't it?
Can this be simplified?
> Third, there is a missing piece though to make it work: The fix for
> XALANJ-2091 is triggered by startPrefixMapping(). With
> FlowJXPathSelectionList.generateSaxFragment() as in the test case
> without the actual CForms framework code startPrefixMapping() is never
> called. After I added startPrefixMapping() at the very beginning of
> FlowJXPathSelectionList.generateSaxFragment() and endPrefixMapping() at
> the end of it (though there is still an issue with the missing
> implementation of the latter [1]) the test passed without the explicit
> removal of the namespace attribute.
Ah, here is the missing detail! :-)
I'm very happy to hear that we have some progress on this annoying issue.
> The question is if we really want to change all places where this
> applies and add start/endPrefixMapping(). In theory that's the correct
> way to do it. Another possibility to fix the tests would be to serialize
> the XML from the actual test run and reparse it in the same way as the
> documents we compare to.
I opt for fixing our code by adding start/endPrefixMapping() as it seems to be the cleanest possible
solution. Apart from that I think that SAX spec. enfornces on us to use these methods if we want to
produce proper (representing well-formed XML) stream of SAX events.
I'm happy to help (or even take care of all the task) with fixing our code.
The only problem I can see now is that Xalan 2.7.1 is _not_ available on Maven central repository.
Do you have an idea how to quickly add it to repository? Should we ask Xalan people to upload it or
should we go for standard procedure (creating issue in Maven jira and attaching artifacts)?
What's more, it seems that jars of older Xalan versions available on Maven repository is not the
same as jars in archive downloaded from Xalan site. The later is split into two jars:
* xalan.jar
* serializer.jar
whereas jar from repository has classes from both xalan.jar and serializer.jar.
--
Grzegorz Kossakowski
Re: svn commit: r597535 - in /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src:
main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
Posted by Joerg Heinicke <jo...@gmx.de>.
Grek, thanks for your work on this. I figured out the missing pieces.
First, I did not know that DOM is slightly different than the theory of XML.
On 27.12.2007 12:46 Uhr, Grzegorz Kossakowski wrote:
> Grzegorz Kossakowski pisze:
>> 3. My gut feeling is that we are affected by XALANJ-2091[2] bug. I'll try to verify my feelings
>> tomorrow.
>
> I have checked if update to Xalan 2.7.1 helps and it's not. Anyway, after taking closer look at our
> code it's not a surprise because we don't use DOMBuilder from Xalan but our own class.
Second, that's not quite correct. Xalan 2.7.1 fixes the issue. Our
DOMBuilder is only a wrapper. It does not replace the Xalan DOMBuilder
at all.
Third, there is a missing piece though to make it work: The fix for
XALANJ-2091 is triggered by startPrefixMapping(). With
FlowJXPathSelectionList.generateSaxFragment() as in the test case
without the actual CForms framework code startPrefixMapping() is never
called. After I added startPrefixMapping() at the very beginning of
FlowJXPathSelectionList.generateSaxFragment() and endPrefixMapping() at
the end of it (though there is still an issue with the missing
implementation of the latter [1]) the test passed without the explicit
removal of the namespace attribute.
The question is if we really want to change all places where this
applies and add start/endPrefixMapping(). In theory that's the correct
way to do it. Another possibility to fix the tests would be to serialize
the XML from the actual test run and reparse it in the same way as the
documents we compare to.
Joerg
Re: svn commit: r597535 - in /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src:
main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Grzegorz Kossakowski pisze:
> 3. My gut feeling is that we are affected by XALANJ-2091[2] bug. I'll try to verify my feelings
> tomorrow.
I have checked if update to Xalan 2.7.1 helps and it's not. Anyway, after taking closer look at our
code it's not a surprise because we don't use DOMBuilder from Xalan but our own class.
Current problem is that I cannot debug Cocoon in Eclipse (some weird classpath issues) so I lost any
chance to figure out what's wrong. :-(
--
Grzegorz Kossakowski
Re: svn commit: r597535 - in /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src:
main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Joerg Heinicke pisze:
>>
>> I was hit another time by this issue. Are there any news on this? Or
>> do you have any clue what may
>> have caused the change of how documents are parsed and why it seems to
>> be only a problem for test cases?
>
> I can imagine two possible reasons:
> 1. Different class path settings so that a different parser library is
> used, maybe endorsed libs stuff.
> 2. Options on the DocumentBuilderFactory or the SAXParserFactory.
I just checked this issue more carefully and here are my findings:
1. The FlowJXPathSlectionListTestCase has been broken a long time before Giacomo started his work on
Springification of Forms. It was not failing because it was simply excluded from a build process.
2. I checked DOM spec. and it says[1] something contrary to what you have said earlier:
As far as the DOM is concerned, special attributes used for declaring XML namespaces are still
exposed and can be manipulated just like any other attribute.
3. My gut feeling is that we are affected by XALANJ-2091[2] bug. I'll try to verify my feelings
tomorrow.
[1] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Namespaces-Considerations
[2] https://issues.apache.org/jira/browse/XALANJ-2091
--
Grzegorz Kossakowski
Re: svn commit: r597535 - in /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src:
main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
Posted by Joerg Heinicke <jo...@gmx.de>.
On 26.12.2007 20:09 Uhr, Grzegorz Kossakowski wrote:
>>> URL: http://svn.apache.org/viewvc?rev=597535&view=rev
>>> Log:
>>> Fix FlowJXPathSelectionList test-case in a different way:
>>> Since it was the test case that's broken, not our code, fix the issue
>>> in the test case.
>>>
>>> Modified:
>>>
>>> cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java
>>> cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
>>>
>>> + // FIXME: Why is the namespace declaration available as
>>> attribute on the expected document?
>>> + // That's the reason why we have to add it to
>>> destDocument as well.
>>> + destDocument.getDocumentElement().setAttribute("xmlns:" +
>>> FormsConstants.INSTANCE_PREFIX, FormsConstants.INSTANCE_NS);
>> Does anybody have an idea why the namespace declaration is available as
>> attribute on the expected document only after springifing CForms? Is it
>> a classpath issue with an old or inappropriate parser version?
>
> I was hit another time by this issue. Are there any news on this? Or do you have any clue what may
> have caused the change of how documents are parsed and why it seems to be only a problem for test cases?
I can imagine two possible reasons:
1. Different class path settings so that a different parser library is
used, maybe endorsed libs stuff.
2. Options on the DocumentBuilderFactory or the SAXParserFactory.
Joerg
Re: svn commit: r597535 - in /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src:
main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Joerg Heinicke pisze:
> On 22.11.2007 22:49 Uhr, joerg@apache.org wrote:
>> Author: joerg
>> Date: Thu Nov 22 19:49:58 2007
>> New Revision: 597535
>>
>> URL: http://svn.apache.org/viewvc?rev=597535&view=rev
>> Log:
>> Fix FlowJXPathSelectionList test-case in a different way:
>> Since it was the test case that's broken, not our code, fix the issue
>> in the test case.
>>
>> Modified:
>>
>> cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java
>>
>>
>> cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
>>
>
>> + // FIXME: Why is the namespace declaration available as
>> attribute on the expected document?
>> + // That's the reason why we have to add it to
>> destDocument as well.
>> + destDocument.getDocumentElement().setAttribute("xmlns:" +
>> FormsConstants.INSTANCE_PREFIX, FormsConstants.INSTANCE_NS);
>
> Does anybody have an idea why the namespace declaration is available as
> attribute on the expected document only after springifing CForms? Is it
> a classpath issue with an old or inappropriate parser version?
I was hit another time by this issue. Are there any news on this? Or do you have any clue what may
have caused the change of how documents are parsed and why it seems to be only a problem for test cases?
--
Grzegorz Kossakowski
Re: svn commit: r597535 - in /cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src:
main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
Posted by Joerg Heinicke <jo...@gmx.de>.
On 22.11.2007 22:49 Uhr, joerg@apache.org wrote:
> Author: joerg
> Date: Thu Nov 22 19:49:58 2007
> New Revision: 597535
>
> URL: http://svn.apache.org/viewvc?rev=597535&view=rev
> Log:
> Fix FlowJXPathSelectionList test-case in a different way:
> Since it was the test case that's broken, not our code, fix the issue in the test case.
>
> Modified:
> cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionList.java
> cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/test/java/org/apache/cocoon/forms/datatype/FlowJXPathSelectionListTestCase.java
> + // FIXME: Why is the namespace declaration available as attribute on the expected document?
> + // That's the reason why we have to add it to destDocument as well.
> + destDocument.getDocumentElement().setAttribute("xmlns:" + FormsConstants.INSTANCE_PREFIX, FormsConstants.INSTANCE_NS);
Does anybody have an idea why the namespace declaration is available as
attribute on the expected document only after springifing CForms? Is it
a classpath issue with an old or inappropriate parser version?
Joerg