[jdom-interest] Internal DTD subset verification

[Philip Nelson]

--- "Bradley S. Huffman" <hip at a.cs.okstate.edu> wrote:
> Throw this in your copy ./src/java/org/jdom dir and run some tests. I found
> it helps a little but nothing earth shattering.

I have been thinking about this thread and have another option to put on the
table.  Since I haven't run benchmarks (switched to freeBSD and haven't got all
the kinks worked out) I can't say if this will help, but in theory....

If forced to make a choice, I would choose speed over well formedness checks. 
Otherwise I would choose to support both.  I think, after reading these well
thought out arguments, that the default for jdom should be to verify everything
as long as it is possible to turn off verification.  And this is what this
proposal addresses.

What I have attached is a version of Verifier that looks to a resource bundle
for a single property, ShouldVerify.  If true, the default, everything works as
it does now.  All my tests pass with this setting.  An administrator can change
the property to false, affecting the classloader that loads Verifier. In this
case the check* methods will short circuit out, in some cases still doing a
null value check.  The ShouldVerify property is initialized in a static
initializer, so however your classloader is invoked, stand alone, servlet
container etc., it would have to be restarted to change the value.  This means
of course that this solution does not allow changing of the verification
setting at runtime by the program.  I can live with not supporting that use
case.  Most of the other use cases are addressed as far as I can see. I don't
know how the speed would compare to the FastFactory approach, but that deals
with the use case this proposal doesn't support so that's OK too.  SAXBuilder
would use the factory approach because if you didn't do it that way, you
wouldn't have the option to turn verfication on or off for in memory changes.

With this approach, you could have one application that requires verification
and another that doesn't, but having the same application use verification on
some documents but not on others would still require subclassing and possibly a
factory.

This idea could be given higher granularity, ie shouldVerifyElementName etc.,
but I couldn't come up with any really good use cases for that.

apply the diff to Verifier.java and put the properties file in your classpath
ahead of jdom.jar, or put it in your build/classes/org/jdom directory and build
the jar again.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Verifier.diff
Type: application/octet-stream
Size: 1526 bytes
Desc: Verifier.diff
Url : http://jdom.org/pipermail/jdom-interest/attachments/20020505/bf802eb1/Verifier.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Verifier.properties
Type: application/octet-stream
Size: 171 bytes
Desc: Verifier.properties
Url : http://jdom.org/pipermail/jdom-interest/attachments/20020505/bf802eb1/Verifier-0001.obj