"to allow being notified of XInclude inclusions as they occur"

Hi,

I've been looking at the wiki concerning the changes to the Xerces parser needed by OPS:  https://wiki.objectweb.org/ops/Wiki.jsp?page=ThirdPartyJavaLibraries

What is the need to be notified of inclusions?   Shouldn't an include be transparent, in that the resulting file/DOM/whatever looks just like it had fully specified without the include?  

Thanks.

rodney

Caching: if you modify an included file, you need to invalidate the  
cache entry for the document containing the inclusions.

-Erik

On Jul 25, 2008, at 4:35 PM, Rodney Gitzel wrote:
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Ah, that makes sense!  

Is this used anywhere other than in the processors file?   When I modified 3.6 to use the Xerces jars that come with WAS, that was the only location I had to compensate for, i.e. that was the only place I ran into any <include> tags.

I'm thinking that if that *is* the only place it's used, then there may be another way to accomplish the same ends, without modifying the parser.   (And again, this is work we're willing to invest time into, since we're kinda hooped without it.)

Thanks.

rodney

Erik Bruchez wrote

Caching: if you modify an included file, you need to invalidate the  
cache entry for the document containing the inclusions.

-Erik

We have our own XInclude processor which we use in a number of places,  
but we still rely on Xerces in a few places. Mainly, the URL  
generator, when told to perform inclusions, uses Xerces.

An idea would be to simply NEVER use the Xerces XInclude functionality:

* Plus: it is more versatile because you can use it in pipelines, not  
just at parsing time.
* Plus: no dependency on the convoluted Xerces APIs for handling  
caching features.
* Minus: our processor performs basic includes and does not support  
XPointer.

-Erik

On Jul 29, 2008, at 10:00 AM, Rodney Gitzel wrote:
--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Hi Erik,

Let me back up a step and explain what I did to get 3.6 working for us using the Xerces jars that come with WebSphere (this is end result, not order I figured them out):

* remove entire "org.orbeon.oxf.xml.xerces" package
* remove all files from "descriptors/jar/services"
* change package names from "orbeon.apache.xml" to "org.apache.xml" in a half-dozen or so files

Then there were really only two files with code changes:

- XMLUtils.createSAXParserFactory(),

change
            SAXParserFactory factory = new XercesSAXParserFactoryImpl(validating, handleXInclude);
to
         SAXParserFactory factory = SAXParserFactory.newInstance();
            factory.setNamespaceAware(true) ;

- URLGenerator.createOutput,  take out the 'local listener' stuff (since it's gone)

//                                final LocalXIncludeListener localXIncludeListener = new LocalXIncludeListener();
//                                XIncludeHandler.setXIncludeListener(localXIncludeListener);
//                                try {
                                    handler.readXML(pipelineContext, output);
//                                } finally {
//                                    XIncludeHandler.setXIncludeListener(null);
//                                }
//                                localXIncludeListener.updateCache(pipelineContext, configURIReferences);

- remove private class URLGenerator.LocalXIncludeListener


After that we stopped seeing errors about particular parsers.   This DID break the <xi:include> elements in processors.xml, so for the moment we are putting our local processor definitions in there directly (and thus they are 'hard-coded' in our orbeon jar).

If I understand correctly, I may be able to use the Orbeon Xinclude processor to bring back the use of includes in processors.xml?   This would be the one on "org.orbeon.oxf.processor.xinclude"?  Are there other places it would be used I can test against?  And any other suggestions?  I'll tinker with it in 3.6 and see how far I get.

Thanks! :-)

rodney

Erik Bruchez wrote

We have our own XInclude processor which we use in a number of places,  
but we still rely on Xerces in a few places. Mainly, the URL  
generator, when told to perform inclusions, uses Xerces.

An idea would be to simply NEVER use the Xerces XInclude functionality:

* Plus: it is more versatile because you can use it in pipelines, not  
just at parsing time.
* Plus: no dependency on the convoluted Xerces APIs for handling  
caching features.
* Minus: our processor performs basic includes and does not support  
XPointer.

-Erik