#25 improve robustness under J2EE


This is a follow-on to a message,
to the SAX developer list. I'm hoping this way to ensure
this doesn't fall off everyone's radar.


  • Nobody/Anonymous

    Logged In: NO

    Sorry; an obvious duplicate of 631290
    ; for the record I also attempted to attach a file to both
    reports, but it would seem my browser wasn't up to it. :(

  • Anonymous - 2002-10-31

    Logged In: YES

    To summarize, the issue seems to be that some J2EE
    environments emit
    lots of spurious diagnostics from their security policy
    engines because the
    portable bootstrapping uses its execution environment.

    For all that Xerces ships code like this (but is out-of-date
    with respect
    even to the original set of SAX 2.0 bugfixes), I'm hesitant
    to describe
    this as an issue with anything other than those security
    policy engines,
    which are causing false alarms. If there's a real problem
    with SAX it
    should be mentioned in the RFE.

  • Neil Graham

    Neil Graham - 2002-11-01

    Logged In: YES

    The severity of the problems this causes are proportional to
    the completeness of the security implementation in the J2EE
    environment. In older environments, log messages would
    simply get issued, but in more modern ones (Websphere
    Application Server 5 beta, for instance), my understanding is
    that the current SAX code would immediately provoke a
    SecurityException when attempting to get system properties
    or look in jar meta-inf/services entries. Even if the code were
    rewritten to add catch blocks for these cases, such
    operations would still not complete even if the parser lies at
    the heart of the J2EE engine.

    The only way to allow such security-sensitive operations to
    be completed by code lying at the heart of the J2EE platform
    is for that code to use the AccessController's doPrivileged(...)
    method. Then the AccessController can determine the
    context of the caller, determine that it in fact is part of the
    installation and not some foreign code, and allow the
    operation to continue--so the code can behave as advertised.

    Now I'm a parser guy, not a J2EE security guru; so let me
    know if you need any more precise details, and I'll do what I
    can. But this is the way JAXP has gone, which should
    provide an independent, validating perspective on the
    problem. There also don't appear to be too many drawbacks,
    other than a certain partial decommitment from JDK 1.1.8;
    but surely this is a step the API will need to take at some
    point as the Java language continues to evolve.

    As to Xerces's being back-leveled w.r.t. SAX: that's true, but
    orthogonal IMHO; at all events it would be nice if Xerces was
    strictly back-level and didn't have to implement extended
    functionality such as this. The upgrade path would then be
    clear to take as soon as we need no longer conform to the
    JAXP 1.2 TCK. Rest assured Xerces would have updated its
    support by now if that were possible.

  • Anonymous - 2003-07-13
    • priority: 5 --> 4
  • Anonymous - 2003-07-13

    Logged In: YES

    one more point: the SAX API specification clearly doesn't
    specify how the portable bootstrapping is done. It'd be
    perfectly reasonable for some implementation of SAX2
    to ship with code that didn't make the jdk 1.2+ security
    engines get all weepy -- so long as the SAX API was met.

    That is, this is a quality-of-implementation issue, it's
    not an API/interface issue. Any J2EE vendor would
    be well within its rights to change how that logic is


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks