We're using it, but not via the method call you show. Instead, we use something more like the example in XMLGrammarBuilder where you create an XMLGrammarPreparser and parse each schema. Since we're using it for up-front caching rather than in a gathering scenario that works for us. I don't have any performance numbers showing the runtime improvement it gives us, but it's qualitatively worked well. I shied away from XMLGrammarCachingConfiguration because I found it difficult to trap errors when parsing the schema (I'm sure I was just doing something wrong, though).
I do have a somewhat-related question: a recent thread has discussed 2+ levels of schema imports, and, as I understand it, anything after the first level is not parsed because of potential name collisions. Does this A) apply to includes as well as imports (so that everything is in a single namespace) and B) does pre-parsing interpret these additional schemas? Forgive my lack of understanding on this issue....our schemas certainly do this and I hadn't noticed a problem. Alex -----Original Message----- From: Michael Ball [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 1:21 PM To: [EMAIL PROTECTED] Subject: grammar caching Is anyone using this setting in a production environment, we're thinking about it but the documentation says it's experimental. It seems to have been around for a couple years... System.setProperty("org.apache.xerces.xni.parser.XMLParserConfiguration" , "org.apache.xerces.parsers.XMLGrammarCachingConfiguration"); _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
