You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Berin Lautenbach <be...@wingsofhermes.org> on 2004/02/08 04:22:54 UTC
Werner's patch
Peoples,
Have applied Werner's patch. I modified it slightly to move back to
XMLEncryptionExceptions being thrown - more to keep in line with the
rest of the code.
One point - because it is now canonicalising the document, the
circumventBug??? thing is now being called. That means that the
encryption process is now modifying the document (in terms of cascading
name spaces).
I've changed the unit tests to cope with this, but just wanted to flag it.
Cheers,
Berin
RE: One more Xerces dependency
Posted by Scott Cantor <ca...@osu.edu>.
> I'm not sure I understand why it is tied to the parser.
> You can implement a solution for registering/retrieving
> IDs that is not dependent on DOM L3/Xerces, which is what
> we did for JSR 105. It is just a simple Map containing
> Elements and using the ID attribute value as a key...
Sorry, I meant if you wanted the parser to be aware of them. Obviously you
can do it yourself, yes. But there's no way getElementByID or the like will
work then (barring some fairly weird hacking), which may or may not cause
some people problems depending on the APIs they want to use.
-- Scott
RE: One more Xerces dependency
Posted by Donatas Ciuksys <do...@maf.vu.lt>.
Hello everybody,
Sorry for silly question, but where could I find sources of XML-Security 2.0
? Or is CVS the only option ?
Greetings,
Donatas
Re: One more Xerces dependency
Posted by Sean Mullan <Se...@Sun.COM>.
Ok I see, I missed the part in your code where you create a WeakHashMap
of WeakHashMaps (1 per document). I think then you only want the outer map
to be a WeakHashMap and not the inner map, right?
Davanum Srinivas wrote:
> See difference between WeakHashMap and HashMap at
> http://www.onjava.com/pub/a/onjava/2001/07/09/optimization.html?page=2
>
> Basically then the document is gc'ed, i want to get rid of the weakhashmap of the element/id
> pair's in that document.
>
> thanks,
> dims
>
> --- Sean Mullan <Se...@Sun.COM> wrote:
>
>>Hmm, why a WeakHashMap? That seems kind of dangerous if the programmer
>>is not aware you are using a WeakHashMap because entries could be removed if you
>>don't maintain a reference to the key. Or maybe I am missing something.
>>
>>Davanum Srinivas wrote:
>>
>>>Updated bugzilla with a patch that does the following:
>>>- removed the code that registers the id using the xerces hack
>>>- instead store the id/element pair in WeakHashMap's (ONE per document, also a WeakHashMap)
>>>- getElementById looks first in our WeakHashMap table, then looks in uses
>>
>>"doc.getElementById(id)"
>>
>>>This should satisfy both requirements:
>>>- get rid of xerces dependency hack for id's that we register.
>>>- still use standard DOM calls to "GET" id's from the document if it is not registered by us.
>>>
>>>Bugzilla:
>>>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26789
>>>
>>>-- dims
>>>
>>>--- Scott Cantor <ca...@osu.edu> wrote:
>>>
>>>
>>>>I guess the unstated point I'm trying make here is that the best world is
>>>>one in which the standard DOM calls are used in addition to whatever one-off
>>>>solution the libraries decide to implement.
>>>>
>>>>It should be simple to conditionally call those methods (if they exist) as a
>>>>consequence of the proprietary calls. And enable/disable the proprietary
>>>>schema as a library option.
>>>>
>>>>-- Scott
>>>>
>>>
>>>
>>>
>>>=====
>>>Davanum Srinivas - http://webservices.apache.org/~dims/
>>
>>
>
>
> =====
> Davanum Srinivas - http://webservices.apache.org/~dims/
Re: One more Xerces dependency
Posted by Davanum Srinivas <di...@yahoo.com>.
See difference between WeakHashMap and HashMap at
http://www.onjava.com/pub/a/onjava/2001/07/09/optimization.html?page=2
Basically then the document is gc'ed, i want to get rid of the weakhashmap of the element/id
pair's in that document.
thanks,
dims
--- Sean Mullan <Se...@Sun.COM> wrote:
> Hmm, why a WeakHashMap? That seems kind of dangerous if the programmer
> is not aware you are using a WeakHashMap because entries could be removed if you
> don't maintain a reference to the key. Or maybe I am missing something.
>
> Davanum Srinivas wrote:
> > Updated bugzilla with a patch that does the following:
> > - removed the code that registers the id using the xerces hack
> > - instead store the id/element pair in WeakHashMap's (ONE per document, also a WeakHashMap)
> > - getElementById looks first in our WeakHashMap table, then looks in uses
> "doc.getElementById(id)"
> >
> > This should satisfy both requirements:
> > - get rid of xerces dependency hack for id's that we register.
> > - still use standard DOM calls to "GET" id's from the document if it is not registered by us.
> >
> > Bugzilla:
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26789
> >
> > -- dims
> >
> > --- Scott Cantor <ca...@osu.edu> wrote:
> >
> >>I guess the unstated point I'm trying make here is that the best world is
> >>one in which the standard DOM calls are used in addition to whatever one-off
> >>solution the libraries decide to implement.
> >>
> >>It should be simple to conditionally call those methods (if they exist) as a
> >>consequence of the proprietary calls. And enable/disable the proprietary
> >>schema as a library option.
> >>
> >>-- Scott
> >>
> >
> >
> >
> > =====
> > Davanum Srinivas - http://webservices.apache.org/~dims/
>
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: One more Xerces dependency
Posted by Sean Mullan <Se...@Sun.COM>.
Hmm, why a WeakHashMap? That seems kind of dangerous if the programmer
is not aware you are using a WeakHashMap because entries could be removed if you
don't maintain a reference to the key. Or maybe I am missing something.
Davanum Srinivas wrote:
> Updated bugzilla with a patch that does the following:
> - removed the code that registers the id using the xerces hack
> - instead store the id/element pair in WeakHashMap's (ONE per document, also a WeakHashMap)
> - getElementById looks first in our WeakHashMap table, then looks in uses "doc.getElementById(id)"
>
> This should satisfy both requirements:
> - get rid of xerces dependency hack for id's that we register.
> - still use standard DOM calls to "GET" id's from the document if it is not registered by us.
>
> Bugzilla:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26789
>
> -- dims
>
> --- Scott Cantor <ca...@osu.edu> wrote:
>
>>I guess the unstated point I'm trying make here is that the best world is
>>one in which the standard DOM calls are used in addition to whatever one-off
>>solution the libraries decide to implement.
>>
>>It should be simple to conditionally call those methods (if they exist) as a
>>consequence of the proprietary calls. And enable/disable the proprietary
>>schema as a library option.
>>
>>-- Scott
>>
>
>
>
> =====
> Davanum Srinivas - http://webservices.apache.org/~dims/
RE: One more Xerces dependency
Posted by Davanum Srinivas <di...@yahoo.com>.
Updated bugzilla with a patch that does the following:
- removed the code that registers the id using the xerces hack
- instead store the id/element pair in WeakHashMap's (ONE per document, also a WeakHashMap)
- getElementById looks first in our WeakHashMap table, then looks in uses "doc.getElementById(id)"
This should satisfy both requirements:
- get rid of xerces dependency hack for id's that we register.
- still use standard DOM calls to "GET" id's from the document if it is not registered by us.
Bugzilla:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26789
-- dims
--- Scott Cantor <ca...@osu.edu> wrote:
> I guess the unstated point I'm trying make here is that the best world is
> one in which the standard DOM calls are used in addition to whatever one-off
> solution the libraries decide to implement.
>
> It should be simple to conditionally call those methods (if they exist) as a
> consequence of the proprietary calls. And enable/disable the proprietary
> schema as a library option.
>
> -- Scott
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: One more Xerces dependency
Posted by Scott Cantor <ca...@osu.edu>.
I guess the unstated point I'm trying make here is that the best world is
one in which the standard DOM calls are used in addition to whatever one-off
solution the libraries decide to implement.
It should be simple to conditionally call those methods (if they exist) as a
consequence of the proprietary calls. And enable/disable the proprietary
schema as a library option.
-- Scott
Re: One more Xerces dependency
Posted by Sean Mullan <Se...@Sun.COM>.
I'm not sure I understand why it is tied to the parser.
You can implement a solution for registering/retrieving
IDs that is not dependent on DOM L3/Xerces, which is what
we did for JSR 105. It is just a simple Map containing
Elements and using the ID attribute value as a key...
--Sean
Scott Cantor wrote:
>>Back to square one :) Since we can't really wait for or
>>depend on a specific Xerces version, we
>>should fix the problem on our end.
>
>
> Well, that would be nice, but I don't see how. There's no parser-independent
> portable way to set ID attributes during document creation except for DOM3
> which is only supported in recent versions of Xerces, and perhaps a few
> other parsers.
>
> If you're thinking this is fundamentally broken with respect to XML in
> general, you'd be right, but that's another discussion.
>
> -- Scott
>
RE: One more Xerces dependency
Posted by Scott Cantor <ca...@osu.edu>.
> Back to square one :) Since we can't really wait for or
> depend on a specific Xerces version, we
> should fix the problem on our end.
Well, that would be nice, but I don't see how. There's no parser-independent
portable way to set ID attributes during document creation except for DOM3
which is only supported in recent versions of Xerces, and perhaps a few
other parsers.
If you're thinking this is fundamentally broken with respect to XML in
general, you'd be right, but that's another discussion.
-- Scott
RE: One more Xerces dependency
Posted by Davanum Srinivas <di...@yahoo.com>.
Back to square one :) Since we can't really wait for or depend on a specific Xerces version, we
should fix the problem on our end.
-- dims
--- Scott Cantor <ca...@osu.edu> wrote:
> > setAttributeId/setAttributeIdNS - was looking in the Java dox rather than
> > C++. (Java dox on site seem rather old?)
> > Thanks for pointing this out. I will look to see what we can do to remove
> > this dependancy.
>
> If you don't care about earlier Xerces versions, you can certainly rely on
> it in the C++ library (or just test for it in configure and ifdef it).
>
> The Java is trickier because the Xerces version doesn't help you. They won't
> build the DOM3 version as the "official" release yet, so you're left
> probably testing with introspection for it. The docs on the site are for the
> non-DOM3 version, probably.
>
> -- Scott
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: One more Xerces dependency
Posted by Scott Cantor <ca...@osu.edu>.
> setAttributeId/setAttributeIdNS - was looking in the Java dox rather than
> C++. (Java dox on site seem rather old?)
> Thanks for pointing this out. I will look to see what we can do to remove
> this dependancy.
If you don't care about earlier Xerces versions, you can certainly rely on
it in the C++ library (or just test for it in configure and ifdef it).
The Java is trickier because the Xerces version doesn't help you. They won't
build the DOM3 version as the "official" release yet, so you're left
probably testing with introspection for it. The docs on the site are for the
non-DOM3 version, probably.
-- Scott
RE: One more Xerces dependency
Posted by Davanum Srinivas <di...@yahoo.com>.
added a bugzilla bug and a suggested patch as well. I also ran the "mega-sample" ant target to
make sure that nothing is broken. Are there any others i need to run?
-- dims
--- Berin Lautenbach <be...@wingsofhermes.org> wrote:
> >> Unfortunately the DOM API (regardless of level) has no way of
> >> registering that an attribute is of Type ID (except during parse with
> >> a DTD or schema). Level 2 and above have ways of finding
> >> (getElementById) and checking (isId), but no way of setting, other
> >> than at parse time.
> >
> > DOM3 does. Both Java and C++ parsers now support the DOM3 calls to do
> > this.
>
> *^&%$#@$ - feeling like a complete idiot. Totally missed
> setAttributeId/setAttributeIdNS - was looking in the Java dox rather than
> C++. (Java dox on site seem rather old?)
> Thanks for pointing this out. I will look to see what we can do to remove
> this dependancy.
> Dims - Do you mind raising a bugzilla so we can track this?
>
> Cheers,
>
>
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: One more Xerces dependency
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
>> Unfortunately the DOM API (regardless of level) has no way of
>> registering that an attribute is of Type ID (except during parse with
>> a DTD or schema). Level 2 and above have ways of finding
>> (getElementById) and checking (isId), but no way of setting, other
>> than at parse time.
>
> DOM3 does. Both Java and C++ parsers now support the DOM3 calls to do
> this.
*^&%$#@$ - feeling like a complete idiot. Totally missed
setAttributeId/setAttributeIdNS - was looking in the Java dox rather than
C++. (Java dox on site seem rather old?)
Thanks for pointing this out. I will look to see what we can do to remove
this dependancy.
Dims - Do you mind raising a bugzilla so we can track this?
Cheers,
RE: One more Xerces dependency
Posted by Scott Cantor <ca...@osu.edu>.
> Unfortunately the DOM API (regardless of level) has no way of
> registering that an attribute is of Type ID (except during parse with a
> DTD or schema). Level 2 and above have ways of finding (getElementById)
> and checking (isId), but no way of setting, other than at parse time.
DOM3 does. Both Java and C++ parsers now support the DOM3 calls to do this.
-- Scott
Re: One more Xerces dependency
Posted by Davanum Srinivas <di...@yahoo.com>.
that's exactly what they do in Xerces as well :)
http://cvs.apache.org/viewcvs.cgi/xml-xerces/java/src/org/apache/xerces/dom/CoreDocumentImpl.java?annotate=1.62
-- dims
--- Berin Lautenbach <be...@wingsofhermes.org> wrote:
> Dims,
>
> One of our dirty little secrets :>.
>
> Unfortunately the DOM API (regardless of level) has no way of
> registering that an attribute is of Type ID (except during parse with a
> DTD or schema). Level 2 and above have ways of finding (getElementById)
> and checking (isId), but no way of setting, other than at parse time.
>
> Given we build the document as we go and then sign, and we prefer to
> find referenced nodes by Id, we have to register them as we build.
>
> If anyone knows of a better way to register Ids as we build a document,
> I'm very open to suggestions! (If I've missed something in the API -
> let me know!)
>
> The only other thing I can think of would be to actually build our own
> register of Ids as we go. I.e. when IdResolver.getElementById is
> called, we run throught he following steps :
>
> 1. Check the internal Id register. If element is found, return.
> 2. Call Document.getElementById. If this works, register the Id in the
> xml-security register of Ids, then return.
> 3. Work down the current process of finding attributes of the right name
> (but which are not of type ID). If found, register in the xml-security
> register and continue.
>
> That way, we could register the Id ourselves when we build the document.
>
> Cheers,
> Berin
>
> Davanum Srinivas wrote:
>
> > Just found another hard-coded dependency on Xerces in IdResolver.java. Is there anyway to get
> rid
> > of it?
> >
> > public static void registerElementById(Element element, String idValue) {
> > Document doc = element.getOwnerDocument();
> > ((org.apache.xerces.dom.DocumentImpl) doc).putIdentifier(idValue,
> > element);
> > }
> >
> > Thanks,
> > dims
> >
> > =====
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> >
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: One more Xerces dependency
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
Dims,
One of our dirty little secrets :>.
Unfortunately the DOM API (regardless of level) has no way of
registering that an attribute is of Type ID (except during parse with a
DTD or schema). Level 2 and above have ways of finding (getElementById)
and checking (isId), but no way of setting, other than at parse time.
Given we build the document as we go and then sign, and we prefer to
find referenced nodes by Id, we have to register them as we build.
If anyone knows of a better way to register Ids as we build a document,
I'm very open to suggestions! (If I've missed something in the API -
let me know!)
The only other thing I can think of would be to actually build our own
register of Ids as we go. I.e. when IdResolver.getElementById is
called, we run throught he following steps :
1. Check the internal Id register. If element is found, return.
2. Call Document.getElementById. If this works, register the Id in the
xml-security register of Ids, then return.
3. Work down the current process of finding attributes of the right name
(but which are not of type ID). If found, register in the xml-security
register and continue.
That way, we could register the Id ourselves when we build the document.
Cheers,
Berin
Davanum Srinivas wrote:
> Just found another hard-coded dependency on Xerces in IdResolver.java. Is there anyway to get rid
> of it?
>
> public static void registerElementById(Element element, String idValue) {
> Document doc = element.getOwnerDocument();
> ((org.apache.xerces.dom.DocumentImpl) doc).putIdentifier(idValue,
> element);
> }
>
> Thanks,
> dims
>
> =====
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
>
One more Xerces dependency
Posted by Davanum Srinivas <di...@yahoo.com>.
Just found another hard-coded dependency on Xerces in IdResolver.java. Is there anyway to get rid
of it?
public static void registerElementById(Element element, String idValue) {
Document doc = element.getOwnerDocument();
((org.apache.xerces.dom.DocumentImpl) doc).putIdentifier(idValue,
element);
}
Thanks,
dims
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Werner's patch
Posted by Davanum Srinivas <di...@yahoo.com>.
looks good to me. passed the test cases of wss4j.
thanks,
dims
--- Berin Lautenbach <be...@wingsofhermes.org> wrote:
> Peoples,
>
> Have applied Werner's patch. I modified it slightly to move back to
> XMLEncryptionExceptions being thrown - more to keep in line with the
> rest of the code.
>
> One point - because it is now canonicalising the document, the
> circumventBug??? thing is now being called. That means that the
> encryption process is now modifying the document (in terms of cascading
> name spaces).
>
> I've changed the unit tests to cope with this, but just wanted to flag it.
>
> Cheers,
> Berin
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/