Hi Nils
The idea would have been that you get the Handler by using
org.apache.fop.apps.Fop.getDefaultHandler() not by working directly on
the FOTreeBuilder:
https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/Fop.java
Any particular reason why you chose this approach?
Committers, I don't see a problem with what Nils proposes. Does anyone
else? If not, I can do the change next week. If Nils already has a patch
for us, even better. :-)
On 26.06.2005 06:43:22 Nils Meier wrote:
> Hi
>
> I've tried to use FOP for this scenario :
>
> + I have a docbook DOM tree
> + I send it through a transformer using docbook-xsl to generate fo
> + The output of that transformation 'is piped' into the result
> new SAXResult(new FOTreeBuilder)
>
> so no files are generated - the FOTreeBuilder is fed directly
> from an in-memory DOM tree.
>
> Now the subtypes inheriting from FONode contain an identity
> check in:
>
> protected void validateChildNode(Locator loc, String nsURI, String
> localName) throws ValidationException {
> if (nsURI == FO_URI ...
>
> This fails because FO_URI != nsURI *but* FO_URI.equals(nsURI). This
> is so because the generated FO document was dynamically created in
> my setup - apparently without String.intern() for the namespace URI.
>
> I'd propose to replace all those identity checks with .equals() to make
> this safe without relying on intern()-Strings - example:
>
> public class Root extends FObj {
>
> ...
> protected void validateChildNode(Locator loc, String nsURI, String
> localName) throws ValidationException {
> if (FO_URI.equals(nsURI)) {
> ...
>
> Does that sound reasonable? Affects around 30 types in
> org.apache.fop.fo.*
>
> Thanks
> Nils
>
>
>
Jeremias Maerki
