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
