Okay I have placed some breakpoints in SoftReferenceGrammarPool, for the simple example of A and B it seems to work very well, thanks :-)
Now with more complicated schemas that include multiple schemas that include even more schemas, I am not sure whether they are being cached in the pool correctly and then being garbage collected or whether the caching is not working how I would expect. For example after validating a ChangeReportStatusRequest document there are 3 grammars in the pool - “../Reports/CEPC-Reports.xsd”, “../CommonFiles/CommonStructures.xsd”, “ChangeReportStatusRequest.xsd” I then validate a LodgeReportRequest document and after that, there are now only 2 grammars in the pool – “../CommonFiles/CommonStructures.xsd”, “LodgeReportRequest.xsd” I would have assumed that after validating both of those documents, there would now be 4 grammars in the pool. I understand that GC may kick in under strict memory but I am not sure that is the case here? Thanks Adam. ________________________________ From: Michael Glavassevich [mailto:[EMAIL PROTECTED] Sent: 11 November 2008 14:23 To: j-users@xerces.apache.org Cc: Adam Retter Subject: RE: Problem validating using XMLGrammarPool with different Grammars with no namespace Hi Adam, If you want to debug it I would suggest putting breakpoints inside of SoftReferenceGrammarPool [1]. Technically this grammar pool could dump some of the grammars from the cache later (and then reload them if needed) but only if the JVM is starving for memory. Thanks. [1] http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/jaxp/validation/SoftReferenceGrammarPool.java?view=log Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] "Adam Retter" <[EMAIL PROTECTED]> wrote on 11/11/2008 07:42:45 AM: > Ahhhh… > > Great J This seems to work initially. > > Is there a way I can interrogate the GrammarPool or schema loader in > this approach so that I can confirm that grammars are being loaded > once and then re-loaded from the Cache? > > Thanks Adam. > > From: Michael Glavassevich [mailto:[EMAIL PROTECTED] > Sent: 11 November 2008 12:29 > To: j-users@xerces.apache.org > Cc: Adam Retter > Subject: RE: Problem validating using XMLGrammarPool with different > Grammars with no namespace > > Hi Adam, > > Try using the SchemaFactory.newSchema() method. The one which takes > no arguments. It caches based on schema location. That's the one I meant. > > Thanks. > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: [EMAIL PROTECTED] > E-mail: [EMAIL PROTECTED] > > "Adam Retter" <[EMAIL PROTECTED]> wrote on 11/11/2008 > 06:56:06 AM: > > > Michael again thanks for the prompt reply ☺ > > > > I have attempted to use SAXParserFactory, set up the Schemas and > > then use the XMLReader, unfortunately I get exactly the same > > problems as with the XMLGrammarPool approach. I guess internally > > both of these approaches are looking for a documents Schema based on > > its namespace. Because we have duplicate namespaces the second > > document/schema that uses the same namespace as the first > > document/schema fails. > > > > SchemaFactory schemaFactory = SchemaFactory. > > newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI); > > > > Source schemas[] = new Source[] { > > new StreamSource(new File("c:\\1.xsd")), > > new StreamSource(new File("c:\\2.xsd")) > > }; > > > > Schema schema = schemaFactory.newSchema(schemas); > > SAXParserFactory saxParserFactory = SAXParserFactory.newInstance(); > > saxParserFactory.setNamespaceAware(true); > > saxParserFactory.setValidating(true); > > saxParserFactory.setSchema(schema); > > XMLReader reader = saxParserFactory.newSAXParser().getXMLReader(); > > > > > > If I then go on to use XMLReader to validate document a - > > > > <a xsi:noNamespaceSchemaLocation="c:\\1.xsd"></a> > > > > Then validation is fine. > > > > > > However if I try and validate document b - > > > > <b xsi:noNamespaceSchemaLocation="c:\\2.xsd"></b> > > > > Then validation fails with the message - SXXP0003: Error reported by > > XML parser: cvc-elt.1: Cannot find the declaration of element > > 'b'. > > > > > > If however I change the order of the loading of Schemas so that 2. > > xsd is loaded before 1.xsd then document b validates fine and > > document a fails validation (Cannot find declaration of element). > > > > This implies to me that the Validator identifies the relationship > > between documents and their grammar by namespace, because the > > namespace is the same in this case (and probably many other cases), > > validating document b fails because the validator attempts to use > > the schema 1.xsd. > > > > I may have missed something? Or there may be another approach that I > > have not seen? > > > > Otherwise, I would be happy to work with the Xerces team to fix this > > problem; I am sure there must be many different documents and > > grammars out there that whilst different use the same namespace and > > because of this collide - I know I am not the only person who has > > experiences issue. > > > > I would propose that the Schemas location should be used for > > comparison, falling back to the namespace if no location exists. Thoughts? > > > > How can we move this forward please? > > > > > > Thanks Adam. > > ________________________________________ > > From: Michael Glavassevich [mailto:[EMAIL PROTECTED] > > Sent: 10 November 2008 16:56 > > To: j-users@xerces.apache.org > > Subject: RE: Problem validating using XMLGrammarPool with different > > Grammars with no namespace > > > > Hi Adam, > > > > "Adam Retter" <[EMAIL PROTECTED]> wrote on 11/10/2008 > > 11:00:53 AM: > > > > > Thanks for the reply Michael, > > > > > > Regarding the JAXP Validation API - I don't really understand how I > > > can use that with XMLReader for document parsing and validation > > > using SAX. Any ideas? > > > > Start with a SAXParserFactory [1], set the Schema object on it and > > namespace awareness to true. Getting the XMLReader [2] should be > > straightforward from there. > > > > > Regards Xerces, I naively assumed that the Sun JDK fork of Xerces > > > would have very minor changes. > > > > A lot of people assume that but they actually are quite different > > and seem to keep moving on divergent paths. > > > > > Subsequently I have downloaded Xerces 2.9.1 and tried this in place > > > of Sun's Xerces fork, unfortunately I am still getting the same > > > problem and have doubly checked that I am now using org.apache. > > > xerces.* classes and not the Sun ones. > > > > > > Again, looking through the (real) Xerces source I see the same > > > comment in Xerces XMLSchemaValidator albeit now on line 1452. > > > > > > // store the external schema locations. they are set when reset is called, > > > // so any other schemaLocation declaration for the same namespace will be > > > // effectively ignored. becuase we choose to take first location hint > > > // available for a particular namespace. > > > > Unless you're setting the external schema location properties on the > > parser the comment you found is probably a red herring. > > > > > Thanks > > > > Thanks. > > > > [1] http://xerces.apache.org/xerces2- > > j/javadocs/api/javax/xml/parsers/SAXParserFactory.html > > [2] http://xerces.apache.org/xerces2- > > j/javadocs/api/javax/xml/parsers/SAXParser.html#getXMLReader() > > > > Michael Glavassevich > > XML Parser Development > > IBM Toronto Lab > > E-mail: [EMAIL PROTECTED] > > E-mail: [EMAIL PROTECTED] > > > > Registered Office: 7 Abbey Court, Eagle Way, Sowton, Exeter, Devon, EX2 7HY > > Registered Number 2892803 Registered in England and Wales > > > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > > > The information contained in this e-mail is confidential and may be > > subject to > > legal privilege. If you are not the intended recipient, you must not > > use, copy, > > distribute or disclose the e-mail or any part of its contents or take any > > action in reliance on it. If you have received this e-mail in error, please > > e-mail the sender by replying to this message. All reasonable > > precautions have > > been taken to ensure no viruses are present in this e-mail. Landmark > > Information > > Group Limited cannot accept responsibility for loss or damage > > arising from the > > use of this e-mail or attachments and recommend that you subject these to > > your virus checking procedures prior to use. > > Registered Office: 7 Abbey Court, Eagle Way, Sowton, Exeter, Devon, EX2 7HY > Registered Number 2892803 Registered in England and Wales > > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > > The information contained in this e-mail is confidential and may be > subject to legal privilege. If you are not the intended recipient, > you must not use, copy, distribute or disclose the e-mail or any > part of its contents or take any action in reliance on it. If you > have received this e-mail in error, please e-mail the sender by > replying to this message. All reasonable precautions have been taken > to ensure no viruses are present in this e-mail. Landmark > Information Group Limited cannot accept responsibility for loss or > damage arising from the use of this e-mail or attachments and > recommend that you subject these to your virus checking procedures > prior to use. > > www.landmarkinfo.co.uk > Please don't print this email unless you really need to Registered Office: 7 Abbey Court, Eagle Way, Sowton, Exeter, Devon, EX2 7HY Registered Number 2892803 Registered in England and Wales This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email The information contained in this e-mail is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not use, copy, distribute or disclose the e-mail or any part of its contents or take any action in reliance on it. If you have received this e-mail in error, please e-mail the sender by replying to this message. All reasonable precautions have been taken to ensure no viruses are present in this e-mail. Landmark Information Group Limited cannot accept responsibility for loss or damage arising from the use of this e-mail or attachments and recommend that you subject these to your virus checking procedures prior to use.
