So the net result is that people who use code that duplicates this
problem, such as XSS, where the use of the DOM API's is completely out of
their control (or would simply be too expensive to be forced to go back
and fix) cannot use that code with Apache SOAP. That's not really all
that acceptable in my book, and would force me to look elsewhere for a
SOAP engine that does work with my code, but if that's the answer,
whatever. Developers are unlikely to change code that works outside of
Apache SOAP simply to make it work with Apache SOAP.
The Xerces bug you mention is not analogous to this situation. First off,
it was not a bug caused by broad misuse of the DOM API. Second, it was a
new version of Xerces that was not yet in wide circulation; developers had
the choice to simply back down and use older versions of Xerces that they
had probably already been using. Third, it was a problem that was easily
fixed in just a single codebase, rather than one duplicated across a wide
spectrum of codebases.
Another point: many people are not going to see this as a bug in their
code. If it works outside of Apache SOAP, but not within Apache SOAP, the
perception will be that Apache SOAP has the bug, and people won't use
Apache SOAP because of it. Either way, since the DOM2Writer class is
responsible for properly serializing the DOM out to valid, well-formed
XML, it may be nice to have checks in place to ensure that valid
well-formed XML is actually being created.
Ok, well, we should at least document this problem.
And, -1 on your last comment.
- James Snell
Software Engineer, Internet Emerging Technologies, IBM
James M Snell/Fresno/IBM - [EMAIL PROTECTED]
These things I have spoken to you, so that in Me you may have peace.
In the world you have tribulation, but take courage; I have overcome the
world.
- John 16:33
Please respond to [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: Re: Bug with DOM2Writer
> If the change is not made, we run the risk of having code that currently
> works outside of Apache SOAP not work within Apache SOAP, which would be
a
>
> very bad thing. What's the easiest thing to do? I'm sure providing a
First of all, if someone's using DOM2Writer from Apache SOAP then that's
not code that's independent of Apache SOAP. If someone's creating an
incorrect DOM tree then you cannot blame a downstream processor that
does the right thing for the broken results!!
> simple workaround like what I've done here is much better than telling
> users to bugger off and write "proper" code; especially when doing so
> would have an impact on products already on the market.
Sorry, that's not acceptable in my book. We've had cases before where
there were bugs in specific Xerces version which made Apache SOAP
break. We did not go about making "bug-compatible" changes to do
cover that; rather, we reported the bug and waited for them to fix it.
The same has to apply for XSS (and whoever else); if its a bug in their
code then Apache SOAP will not work with that buggy version of their
code.
> But, if you still disagree, I recommend that we put it to a vote.
Well, if it must, fine. I'm -1'ing it for sure.
Also, I recommend that we only take votes from people who've been
participating in the development say in the last 6 months. I know
there are 10+ "sleeper" committers; having them +1 and having that
count is meaningless, at least to me.
I'm sure someone'll throw the process book at me now.
Sanjiva.
