Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
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.
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. :(
Logged In: YES
To summarize, the issue seems to be that some J2EE
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
even to the original set of SAX 2.0 bugfixes), I'm hesitant
this as an issue with anything other than those security
which are causing false alarms. If there's a real problem
with SAX it
should be mentioned in the RFE.
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.
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