Schema validation in production environment

Discussion in 'Java' started by aliptay@gmail.com, Jun 26, 2008.

  1. Guest

    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.
    , Jun 26, 2008
    #1
    1. Advertising

  2. Tom Anderson Guest

    On Thu, 26 Jun 2008, wrote:

    > 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

    --
    They didn't have any answers - they just wanted weed and entitlement.
    Tom Anderson, Jun 26, 2008
    #2
    1. Advertising

  3. Arne Vajhøj Guest

    Tom Anderson wrote:
    > On Thu, 26 Jun 2008, wrote:
    >> 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.


    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
    Arne Vajhøj, Jun 30, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Cheung, Jeffrey Jing-Yen

    Help!!! ASP.NET Crashing in production environment

    Cheung, Jeffrey Jing-Yen, Aug 13, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    387
    Cheung, Jeffrey Jing-Yen
    Aug 13, 2003
  2. Markus
    Replies:
    1
    Views:
    1,528
    Markus
    Nov 23, 2005
  3. Stanimir Stamenkov
    Replies:
    3
    Views:
    1,248
    Stanimir Stamenkov
    Apr 25, 2005
  4. pramodr
    Replies:
    3
    Views:
    839
    Peter Flynn
    Apr 5, 2009
  5. Replies:
    5
    Views:
    1,006
    Brian McCauley
    Nov 29, 2006
Loading...

Share This Page