Hi Asiri/Tharindu, On Jul 24, 2007, at 4:33 PM, Asiri Rathnayake wrote: Thanks for your POV but I think we're not talking about the same thing at all.... :) I know exceptions are useful in general and I agree with that of course... I said "IF our goal is to implement the Confluence XMLRPC interface". I think this is our goal. Why are we doing this? For one reason I can see: that anyone who has code that interacts with Confluence can use that code to interact with XWiki. So 2 advantages: - we don't create yet a new API - confluence tools can work seamlessly with XWiki Of course that'll work well only if we implement the real confluence API... and that confluence API doesn't throw any exception AFAIK. BTW it's funny that you want to keep the exceptions since it's because of your patch that I'm proposing to remove them... ;) You created a patch that returns a boolean in addition to throwing an exception. This is obviously wrong as they serve the same purpose. In conclusion we need to choose: 1) either we want to implement the Confluence API and we should drop the exceptions 2) either we don't want and then we shouldn't call it ConfluenceRpcInterface and then we can throw exceptions... Hope this makes it more clear, Thanks -Vincent

Hi and sorry for the delayed response, On 7/24/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote: 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). "It is recommended to use the property enabledForExceptions. If this property is set, then the server will attempt to convert the exception into a byte array, which is transmitted to the client. The client will be able to convert the byte array back into an exception and throw that, as if it came right out of the client. Note, that this approach may cause security and privacy issues, because the serialized exception may, in theory, contain arbitrary objects." 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. [snip] Please name the methods which caused you trouble and I'll look into it. Regards, Catalin

Hi Asiri, On 8/10/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote: [snip] I agree on this not only for the reason you mention, but also because I find the exception mechanism in XWiki very cumbersome. It seems that having to write 3 lines of code to throw an exception causes many to just not throw them at all. But sure, the primary reason for going with standard Java exceptions in the XML-RPC implementation would be interoperability. What do the others think? Are there good reasons for using XWikiException here? [snip] Asiri, if the interface says void then i would stick to void, the same way we should stick with boolean when the interface says so. I will look into other ways to fix these problems (i.e. ways that don't involve changing the API) and come back to you. Regards, Catalin

Hi Catalin, On 8/10/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote: Many thanks for finding this. Regards, - Asiri Regards,

On Aug 9, 2007, at 9:20 PM, Catalin Hritcu wrote: [snip] 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? [snip] 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... [snip] Thanks Catalin for looking into this -Vincent

Hi, There is something i need to add. On 8/10/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> 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. Regards, Catalin

Hello, On 7/24/07, Vincent Massol <vincent(a)massol.net> wrote: [snip] [snip] I have a couple of questions regarding this. What are the advantages of really implementing the Confluence API (now we don't really do it!)? Is there anybody who needs to use both? Is there any tool which would be able to use Confluence and XWiki interchangeably? For example will Xeclipse support both Confluence and XWiki? Regards, Catalin

Hi Vincent, Thanks for the answer, now I understand better and I agree that this is be a Good Thing. On 7/25/07, Vincent Massol <vincent(a)massol.net> wrote: [snip] What about "gracefully degrading" the functionality if the xwiki-only features are not present, but continuing to work with any confluence-interface-conform implementation ? Regards, Catalin