Schema validation in production environment

[aliptay]

Hi,

Specifically, we're using Spring 2.5 and Xerces jaxp
SAXParserFactoryImpl parser. At some point in time last week, we
couldn't reach http://www.springframework.org/schema/security/spring-security-2.0.1.xsd
and our system froze.

Generally, what is the best approach to avoid schema and dtd
dependencies? I know most spring xsd's are defined in the
spring.schemas, but we have some DTD and Schema references which do
not have a local reference. Should I:

1. Make all schema location references local?

2. Forgo default schema validation in our production environment?

Making #1 work appears to be non-trivial for the various environments
we use the code in (Eclipse, JUnit, QA, Production) (ie. the absolute
folder the relative location references seems to change)

For #2, how do you specify a default schema validation of false with
Xerces? The best I could do is extend both the DocumentBuilder and
Parser and set the validation to false programmatically the first time
newParser or newBuilder is called.

Can someone shed some light as to best practices regarding this?

Thanks,
Albert.

 

[Tom Anderson]

Specifically, we're using Spring 2.5 and Xerces jaxp
SAXParserFactoryImpl parser. At some point in time last week, we
couldn't reach
http://www.springframework.org/schema/security/spring-security-2.0.1.xsd
and our system froze.

Generally, what is the best approach to avoid schema and dtd
dependencies? I know most spring xsd's are defined in the
spring.schemas, but we have some DTD and Schema references which do
not have a local reference. Should I:

1. Make all schema location references local?

2. Forgo default schema validation in our production environment?

No.

You should get copies of all the schemata you need, and store them
locally, somehow keyed by their defining URL (use a database, or DBM, or
escape the URLs and use them as filenames, or just use a text file to
index them, etc). You should then write a class which will take URLs and
resolve them to schemata using your local store, and plug this into your
parser.

I don't actually know how you plug such a class into a parser, but i
pretty much guarantee that it can be done. It'd be complete madness if it
couldn't.

I *think* it's just a question of implementing EntityResolver, but i'm not
sure this is used to resolve schemata. I'd create an implementation of
this which resolves entities by opening their URLs, as is the default, but
logs the calls - that way, you can see exactly what it's handling, and
tell quickly if this is the right thing to do.

As for actually getting the data to the code in different environments,
i'd put the schema files or whatever in your classpath, and access them
via Class.getResourceAsStream. This will work in all environments, whether
the code is files in directories or JARred up.

tom

 

[Arne Vajhøj]

No.

You should get copies of all the schemata you need, and store them
locally, somehow keyed by their defining URL (use a database, or DBM, or
escape the URLs and use them as filenames, or just use a text file to
index them, etc). You should then write a class which will take URLs and
resolve them to schemata using your local store, and plug this into your
parser.

I don't actually know how you plug such a class into a parser, but i
pretty much guarantee that it can be done. It'd be complete madness if
it couldn't.

I *think* it's just a question of implementing EntityResolver, but i'm
not sure this is used to resolve schemata. I'd create an implementation
of this which resolves entities by opening their URLs, as is the
default, but logs the calls - that way, you can see exactly what it's
handling, and tell quickly if this is the right thing to do.

DocumentBuilder.setEntityResolver works for both DTD's and schemas.

But the code validating against external DTD/schema URL's are very
likely external libraries, where one has no control over the code
(can not call DocumentBuilder.setEntityResolver).

Well - most of it is open source, so one could download the source,
hack it and build. But that is not an elegant solution.

Arne