Hi VIshal,
This is going to be one of the features for 1.4.1 with the
DocumentBuilder polling.
I want to take out all the comparisons with namespaces and let the API
user to decide how lax he wants to be with the strictness of the
elements. He can disable namespace checking altogether or do it wit
Hi Raul,
Could you think of a way we can fix the problem without having a
significant performance hit. This clearly is a blocking issue for me. If
eventually we decide to change the comparisons to use String.equals() I
could give you the list of all relevant occurrences in the code.
Thanks,
Hi Sean,
The penalty hit is taken when the strings are not equal, sadly of the
same length.
And have a lot of common begging characters. That is sadly a common
problem with namespaces URI, they are more or less equal in length and
have a lot of damn http://.../... or urn:: whatever at the
beg
Wait, I spoke too soon, I see the test is != (instead of ==) so using
!String.equals would be slower than != with interned Strings because it
has to do the full String.equals test.
But what if we reversed the test, i.e.:
if (namespaceSHOULDBE.equals(namespaceIS) &&
localnameSHOULDBE.equals
String.equals will work for both interned and non-interned Strings,
since it first checks if they are a reference to the same object. So
using String.equals seems safer and should be comparable performance I
would think. But maybe I'm missing something?
--Sean
Vishal Mahajan wrote:
Do others
Hi Vishal,
My point is that I think that is good to have compatibility with
different DOM parsers,but so far I have no found no one that no works
with current xml-sec even I have try xerces1 & crimson (at least I
remember doing a test, but with JAXP & Xmlbeans I'm sure). If it is
not possible to c
Do others also have views on this discussion?
Thanks,
Vishal
Vishal Mahajan wrote:
Hi Raul,
The parser that I am working with clearly doesn't intern element
namespace strings which is the reason I ran into this problem. And
actually I am not sure whether it's a good idea for a parser to inte
Hi Raul,
The parser that I am working with clearly doesn't intern element
namespace strings which is the reason I ran into this problem. And
actually I am not sure whether it's a good idea for a parser to intern
element namespace strings given that there could be huge number of
elements being
Vishal the problem is that this codes is called gazillion of times, and even it
seems a small thing, it takes a lot of accumulated time, I even think
in remove this checking altogether or control it by a property.
Perhaps there is a feature set in your DOM parser that interns the
namespaces. I hav
There are few more similar occurrences that I found (patch attached)
that should be fixed.
Vishal
Vishal Mahajan wrote:
Any signature verification was failing for me, and I have a different
DOM implementation in my environment, so probably you are right. It
was such a basic error that it had
Any signature verification was failing for me, and I have a different
DOM implementation in my environment, so probably you are right. It was
such a basic error that it had to be something like this. In any case, I
think we should keep string comparison safe.
Vishal
Raul Benito wrote:
Hi Vis
Hi Vishal,
The namespaces strings are intern, at least in xerces.
Can you post the code that is failing?
On 10/2/06, Vishal Mahajan <[EMAIL PROTECTED]> wrote:
This problem was not allowing successful creation of signature space
elements. Fix attached.
Vishal
Index: ElementProxy.java
==
12 matches
Mail list logo
