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
