You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Robert Huffman <ro...@gmail.com> on 2013/01/12 23:04:17 UTC
Caching grammars
I must parse documents that may use a large number of fairly large XSDs.
However, the large majority of documents will not use most of those XSDs.
Therefore, I would like to use a custom LSResourceResolver to resolve the
target namespaces to local resources during parsing rather than building a
Schema object that has all the grammars loaded up front.
Unfortunately, as nearly as I can tell, grammars loaded through the use of
a LSResourceResolver are never cached in the grammar pool. Is that correct?
Is there some nuance I'm missing?
Re: Caching grammars
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Xerces' grammar objects are thread-safe. The ones cached in the JAXP
Schema object are shared with each Validator created from the JAXP Schema.
Thanks.
Michael Glavassevich
XML Technologies and WAS Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Robert Huffman <ro...@gmail.com> wrote on 20/01/2013 01:59:33 PM:
> That does seem to be the way it works. I dug into the source more
> after my initial post. It seems that the grammar pool in the Schema
> is used to initialize a second grammar pool owned by the Validator.
> This second grammar pool lives only as long as the validator.
>
> I haven't gotten back into that part of my code in a week or so, but
> I believe I can ultimately get my grammars that are dynamically
> loaded via the LSResourceResolver by reusing my Validator. Of
> course, the Validator is not thread-safe, so I will probably use a
> ThreadLocal<Validator>. (Synchronizing a single validator is
> probably not acceptable in my environment.)
>
> Of course, that means I will end up with a grammar cache in each
> thread in my thread pool. So my next step is to figure out if the
> grammars are thread safe. If they are, perhaps I can figure out a
> way to share a single instance of a thread safe grammar cache
> between validators.
>
> On Sun, Jan 20, 2013 at 10:23 AM, Michael Glavassevich
<mrglavas@ca.ibm.com
> > wrote:
> The JAXP Schema created through SchemaFactory.newSchema() caches
grammars
> (through SoftReferences [1]) by their schema location. It's been quite
> awhile since I've looked at how this works, but it wouldn't surprise me
if
> Xerces calls your LSResourceResolver each time you validate in order to
> give your application an opportunity to redirect the schema location and
> then use the value returned from the LSResourceResolver to look up the
> cached grammar.
>
> Thanks.
>
> [1]
> http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/
> xerces/jaxp/validation/SoftReferenceGrammarPool.java?annotate=699892
>
> Michael Glavassevich
> XML Technologies and WAS Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> Robert Huffman <ro...@gmail.com> wrote on 12/01/2013 05:04:17
PM:
>
> > I must parse documents that may use a large number of fairly large
> > XSDs. However, the large majority of documents will not use most of
> > those XSDs. Therefore, I would like to use a custom
> > LSResourceResolver to resolve the target namespaces to local
> > resources during parsing rather than building a Schema object that
> > has all the grammars loaded up front.
> >
> > Unfortunately, as nearly as I can tell, grammars loaded through the
> > use of a LSResourceResolver are never cached in the grammar pool. Is
> > that correct? Is there some nuance I'm missing?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org
Re: Caching grammars
Posted by Robert Huffman <ro...@gmail.com>.
That does seem to be the way it works. I dug into the source more after my
initial post. It seems that the grammar pool in the Schema is used to
initialize a second grammar pool owned by the Validator. This second
grammar pool lives only as long as the validator.
I haven't gotten back into that part of my code in a week or so, but I
believe I can ultimately get my grammars that are dynamically loaded via
the LSResourceResolver by reusing my Validator. Of course, the Validator is
not thread-safe, so I will probably use a ThreadLocal<Validator>.
(Synchronizing a single validator is probably not acceptable in my
environment.)
Of course, that means I will end up with a grammar cache in each thread in
my thread pool. So my next step is to figure out if the grammars are thread
safe. If they are, perhaps I can figure out a way to share a single
instance of a thread safe grammar cache between validators.
On Sun, Jan 20, 2013 at 10:23 AM, Michael Glavassevich
<mr...@ca.ibm.com>wrote:
> The JAXP Schema created through SchemaFactory.newSchema() caches grammars
> (through SoftReferences [1]) by their schema location. It's been quite
> awhile since I've looked at how this works, but it wouldn't surprise me if
> Xerces calls your LSResourceResolver each time you validate in order to
> give your application an opportunity to redirect the schema location and
> then use the value returned from the LSResourceResolver to look up the
> cached grammar.
>
> Thanks.
>
> [1]
>
> http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/jaxp/validation/SoftReferenceGrammarPool.java?annotate=699892
>
> Michael Glavassevich
> XML Technologies and WAS Development
> IBM Toronto Lab
> E-mail: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> Robert Huffman <ro...@gmail.com> wrote on 12/01/2013 05:04:17 PM:
>
> > I must parse documents that may use a large number of fairly large
> > XSDs. However, the large majority of documents will not use most of
> > those XSDs. Therefore, I would like to use a custom
> > LSResourceResolver to resolve the target namespaces to local
> > resources during parsing rather than building a Schema object that
> > has all the grammars loaded up front.
> >
> > Unfortunately, as nearly as I can tell, grammars loaded through the
> > use of a LSResourceResolver are never cached in the grammar pool. Is
> > that correct? Is there some nuance I'm missing?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-users-help@xerces.apache.org
>
>
Re: Caching grammars
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
The JAXP Schema created through SchemaFactory.newSchema() caches grammars
(through SoftReferences [1]) by their schema location. It's been quite
awhile since I've looked at how this works, but it wouldn't surprise me if
Xerces calls your LSResourceResolver each time you validate in order to
give your application an opportunity to redirect the schema location and
then use the value returned from the LSResourceResolver to look up the
cached grammar.
Thanks.
[1]
http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/jaxp/validation/SoftReferenceGrammarPool.java?annotate=699892
Michael Glavassevich
XML Technologies and WAS Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Robert Huffman <ro...@gmail.com> wrote on 12/01/2013 05:04:17 PM:
> I must parse documents that may use a large number of fairly large
> XSDs. However, the large majority of documents will not use most of
> those XSDs. Therefore, I would like to use a custom
> LSResourceResolver to resolve the target namespaces to local
> resources during parsing rather than building a Schema object that
> has all the grammars loaded up front.
>
> Unfortunately, as nearly as I can tell, grammars loaded through the
> use of a LSResourceResolver are never cached in the grammar pool. Is
> that correct? Is there some nuance I'm missing?
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org