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. Ferrell
-----Original Message----- From: Aleksey Sanin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 28, 2002 9:39 PM To: Moultrie, Ferrell (ISSAtlanta) Cc: [EMAIL PROTECTED] 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 OpenSSL. 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 xmlSecErrorsSetCallback() function. This gives you *no* information about the current document processed. Aleksey. Moultrie, Ferrell (ISSAtlanta) wrote: >Aleksey: > 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 open >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? Any >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 solution, >IMO. >Thanks! > Ferrell > >===================================== >Ferrell Moultrie ([EMAIL PROTECTED]) >Software Engineer > >Internet Security Systems, Inc. >6303 Barfield Road >Atlanta, Georgia 30328 >Phone: 404-236-2600 >Direct: 404-236-2849 >Fax: 404-236-2632 >http://www.iss.net > >Internet Security Systems -- The Power to Protect >===================================== >_______________________________________________ >xmlsec mailing list >[EMAIL PROTECTED] >http://www.aleksey.com/mailman/listinfo/xmlsec > > _______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
