Re: [Spacewalk-devel] Patch proposal: try-wrapping XMLRPC serialization code

[Grant Gainey]

Hey Silvio,

- Original Message -
> Hi,
> 
> We had a downstream bug that boiled down to an uncaught exception in
> XMLRPC serialization code (a class implementing XmlRpcCustomSerializer).
> 
> AFAIU at the moment any uncaught exception from by the serialize() is
> basically ignored, "digested" by the redstone library and not added to
> any log or error output, making it quite hard to find out issues. I
> would like to add some code to add some exception details to the error log.
> 
> You can easily reproduce the bug on basically any Spacewalk version by
> adding a line like this:
> 
> throw new NullPointerException();
> 
> to ServerSerializer.serialize(), then calling via API any XMLRPC method
> that returns a server.
> 
> Proposed solution would be to try-wrap all serialize() methods in the
> application, which is the only way I can think of to handle those
> exceptions in Spacewalk code, since this problem really stems from
> redstone. Creating a superclass is unfortunately not an option because
> the serialize() method signature can change.
> 
> Any feedback or better idea is welcome. In case this is really the only
> viable solution, would you accept such a patch?

I decided there *had to* be a better way to do this - and I found one!

See commit 1fddc7359c54dcfae38505c55a6074144685e2f5 - built an abstract base 
class, refactored[1] the FooSerializer classes to extend it, and made 
SerializerFactory less dumb (and smaller!)

I've tested a number of random API calls, and the serialization JUnits pass, 
but More Eyes would be great.  Also, RhnXmlRpcCustomSerializer.serialize() 
could probably do something better in terms of logging.

Let me know what you think!

G

[1] Between sed and Eclipse, *nothing* is safe :)

> 
> Regards,
> --
> Silvio Moioli
> SUSE LINUX Products GmbH
> Maxfeldstraße 5, 90409 Nürnberg Germany
> 
> ___
> Spacewalk-devel mailing list
> Spacewalk-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-devel
>

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] [PATCH] spacecmd: Fix session validation

[David Juran]

Turns out that although spacewalk (Red Hat Satellite 5.5) takes a
session argument for the api.getApiNamespaces() API call, this session is not
validated, i.e. the call will succeed no matter if the session is
valid or not. Which makes this particular call quite a bad choice
validating the session... Trying now to use user.listAssignableRoles
instead
---
 spacecmd/src/lib/misc.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/spacecmd/src/lib/misc.py b/spacecmd/src/lib/misc.py
index dff6fb3..f2769d5 100644
--- a/spacecmd/src/lib/misc.py
+++ b/spacecmd/src/lib/misc.py
@@ -307,7 +307,7 @@ def do_login(self, args):
 try:
 logging.debug('Using cached credentials from %s' % session_file)
 
-self.client.api.getApiNamespaces(self.session)
+self.client.user.listAssignableRoles(self.session)
 except:
 logging.warning('Cached credentials are invalid')
 self.current_user = ''
-- 
1.8.3.1

-- 
David Juran
Sr. Consultant
Red Hat
+46-725-345801

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel