[xmlsec] request/complaint -- new error reporting feature

Aleksey Sanin aleksey at aleksey.com
Wed Aug 28 19:40:15 PDT 2002

XMLSec is based on OpenSSL by itself and uses the errors reporting 
by itself. As you can imagine, I do not want to deal with TLS either :)
Also there is one more advantage in looking into the OpenSSL errors 
stack -- you will
get any crypto error from OpenSSL this way :)
BTW, there is a usefull flag 'xmlSecPrintErrorMessages' declared in 
xmlsec/errors.h file
that allows you to control whether standard XMLSec errors handler prints 
error to the LibXML2.
If it set to 0 then default XMLSec errors handlers reports errors to 
OpenSSL only.


Moultrie, Ferrell (ISSAtlanta) wrote:

>Hmmm .. yes, I guess I'm more used to a C++ world where there's usually
>some parent object that the library can retrieve the context information
>from. Having to pass it through to all the functions would be a pain.
>libxml2 as well as OpenSSL use the thread-local approach and I really
>anticipated that would be how you would implement that. I guess I can do
>the same thing within my code but TLS is a nasty trick in cross-platform
>code and I usually prefer to see that done within libraries rather than
>pushed back into the application space. If you don't think this belongs
>in xmlsec itself, I'll probably just use the openssl error stack. If
>nothing else, that should handle the cascade of errors that seem to
>occur when anything goes wrong deep inside xmlsec. The first error is
>the most meaningful, the last is rather generic. Having a stack will let
>me work around that nicely. Thanks for the consideration .. your
>existing plan is adequate, just not what I had mentally expected based
>on my experience with other libraries.
>-----Original Message-----
>From: Aleksey Sanin [mailto:aleksey at aleksey.com] 
>Sent: Wednesday, August 28, 2002 9:39 PM
>To: Moultrie, Ferrell (ISSAtlanta)
>Cc: xmlsec at aleksey.com
>Subject: Re: [xmlsec] request/complaint -- new error reporting feature
>There are some problems with "void* context" parameter for error 
>reporting function
>and the main one is that if you really want to do it then you have to 
>pass this "context"
>paramer in *all* your functions (which is ugly :( ).
>In real life there are few possible workarounds and the most popular one
>is to use
>thread context storage (per thread specific values). For example, 
>OpenSSL does this
>for its error reporting.
>Another option would be to wait till the end and analize the errors 
>stack provided
>by OpenSSL since default XMLSec errors handler reports all errors to 
>This gives you context (doc, etc.) and does not require any thread 
>context storage.
>And I am not sure I get your idea about passing "context" to the 
>function. This gives you *no* information about the current document 
>Moultrie, Ferrell (ISSAtlanta) wrote:
>> Ok .. I'm trying to use the new xmlsec error reporting feature.
>>There's one thing that was apparently overlooked -- I can only register
>>one global static function and there's no context reported to that
>>function (only file, line, func, reason, and msg -- none of which I
>>control). So, when my callback function gets control, it has no way to
>>know which document the error relates to (I have multiple documents
>>for verification operations concurrently). 
>> The libxml2 error function registration while not giving me nearly as
>>much/nice information as yours does -- at least allows me to register a
>>(void*) context pointer which I can use to figure out the document
>>context to which the call applies. 
>> Have I missed something obvious (again!) or was this an oversight?
>>thoughts about fixing/improving it if so? Passing a context pointer on
>>the xmlSecErrorsSetCallback() method and then supplying it as a new
>>parameter to the callback function would be a quite sufficient
>> Ferrell
>>Ferrell Moultrie (ferrell at iss.net)
>>Software Engineer
>>Internet Security Systems, Inc.
>>6303 Barfield Road
>>Atlanta, Georgia 30328
>>Phone:  404-236-2600
>>Direct: 404-236-2849
>>Fax:    404-236-2632
>>Internet Security Systems -- The Power to Protect
>>xmlsec mailing list
>>xmlsec at aleksey.com
>xmlsec mailing list
>xmlsec at aleksey.com

More information about the xmlsec mailing list