11 Aug
2007
11 Aug
'07
9:33 p.m.
Just seen this email before I replied in my other email...
-Vincent
On Aug 10, 2007, at 10:42 AM, Catalin Hritcu wrote:
Hi,
There is something i need to add.
On 8/10/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
Regards,
Catalin
--
You receive this message as a subscriber of the xwiki-
dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/
wws
Hi Vincent,
On 8/10/07, Vincent Massol <vincent(a)massol.net> wrote:
This is the case only when one uses dynamic proxies (like we are now).
The XmlRpcClient.execute method will wrap the exception the server
sends into a XmlRpcException which it will throw. The dynamic proxy
then unwraps it and re-throws the original exception.
As far as I know swizzle does not catch exceptions, so it will just
let the XmlRpcException propagate, which means they don't really need
a "throws Exception" clause on every method, but just a "throws
XmlRpcException, IOException". Maybe we can have this as another
modification to swizzle.
On Aug 9, 2007, at 9:20 PM, Catalin Hritcu wrote:
[snip]
Yes, but this is more or less what they have to do now anyway (catch
Exception). And swizzle does have a "throws Exception" on every
method.
I checked and confluence does throw exceptions
for all erroneous
situations. Also all methods in swizzle-confluence (a client-side
proxy for the confluence remote api) have a "throws Exception"
clause.
This means it makes a lot of sense to always throw an exception
when
something goes topsy-turvy on the server (now the behavior
depends on
mood of the writer of each method, and we don't check for many
error
conditions).
For exceptions to be sent back to the client we need to enable
them on
the server using the "enabledForExtensions" parameter (currently
it's
turned off).
But we can't do this, right. If we do we might break clients tools
such as swizzle, unless they do a big catch of Exception or
Throwable
and treat them generically.
What exception gets out of XMLRPC on the client
side? The typed
exception sent on the server or some XMLRPC client side exception
class?
This depends on many things.
1. If the server is not enabled for exceptions but an exception is
thrown on the server then the client will try to throw a generic
XmlRpcException saying that something went bad, but no reason is
given. However, this works only if the method has a "throws
XmlRpcException" clause (which is usually not the case). Otherwise
the
client will throw a runtime exception (UndeclaredThrowableException).
This is what happens now.
2. If the server is enabled for exceptions then the client will
try to
re-throw the original exception. This is what I would like to have
soon.
[snip]
Sure, I will do that.
Regards,
Catalin
This is true. The confluence API specifies
boolean return types for
some methods just because of bugs in some xml-rpc implementations.
For example:
boolean logout(String token) - remove this token from the list of
logged in tokens. Returns true if the user was logged out, false if
they were not logged in in the first place (we don't really need
this
return, but void seems to kill XML-RPC for me)
Anyway, we should stick to what the API specification says, and
sometimes that means returning meaningless booleans.
Fine with me *provided* we document this in our XMLRPC classes so
that the next person that looks at it understand why there are 2
ways
to return stuff...