Why do we throw exceptions in the ConfluenceRpcInterface methods?
Hi, If our goal is to implement the Confluence XMLRPC interface (http:// confluence.atlassian.com/display/DOC/Remote+API+Specification) then it seems to me we shouldn't throw XWikiException in any method in our ConfluenceRpcInterface interface. Several methods instead should return a boolean to indicate success or failure. Does anyone know why we're throwing them? Are we ok to remove all exception throwing? Thanks -Vincent
On 7/24/07, Vincent Massol <vincent@massol.net> wrote:
Hi, If our goal is to implement the Confluence XMLRPC interface ( http://confluence.atlassian.com/display/DOC/Remote+API+Specification) then it seems to me we shouldn't throw XWikiException in any method in our ConfluenceRpcInterface interface. Several methods instead should return a boolean to indicate success or failure.
Does anyone know why we're throwing them?
I believe the reason is that we should be able to indicate to the user about what went wrong on the server. This is very useful since there may be situations where the user needs some help with. For an example if the user enters a wrong password when logging in, the exception says that something is wrong with logging details (or so it should). Similar situations apply for other operations as well. But having said that, the current implementation does not provide much help with error messages, we need to improve it. Are we ok to remove all exception throwing?
I don't think this is a good idea. But we'll wait for other opinions. Thanks. Best Regards, - Asiri Thanks
-Vincent
-- You receive this message as a subscriber of the xwiki-dev@objectweb.orgmailing 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 Asiri/Tharindu, On Jul 24, 2007, at 4:33 PM, Asiri Rathnayake wrote:
On 7/24/07, Vincent Massol <vincent@massol.net> wrote: Hi,
If our goal is to implement the Confluence XMLRPC interface ( http://confluence.atlassian.com/display/DOC/Remote+API +Specification) then it seems to me we shouldn't throw XWikiException in any method in our ConfluenceRpcInterface interface. Several methods instead should return a boolean to indicate success or failure.
Does anyone know why we're throwing them?
I believe the reason is that we should be able to indicate to the user about what went wrong on the server. This is very useful since there may be situations where the user needs some help with. For an example if the user enters a wrong password when logging in, the exception says that something is wrong with logging details (or so it should). Similar situations apply for other operations as well. But having said that, the current implementation does not provide much help with error messages, we need to improve it.
Are we ok to remove all exception throwing?
I don't think this is a good idea. But we'll wait for other opinions.
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 Vincent, On 7/24/07, Vincent Massol <vincent@massol.net> wrote:
Hi Asiri/Tharindu, On Jul 24, 2007, at 4:33 PM, Asiri Rathnayake wrote:
On 7/24/07, Vincent Massol <vincent@massol.net> wrote:
Hi, If our goal is to implement the Confluence XMLRPC interface (http://confluence.atlassian.com/display/DOC/Remote+API+Specification) then it seems to me we shouldn't throw XWikiException in any method in our ConfluenceRpcInterface interface. Several methods instead should return a boolean to indicate success or failure.
Does anyone know why we're throwing them?
I believe the reason is that we should be able to indicate to the user about what went wrong on the server. This is very useful since there may be situations where the user needs some help with. For an example if the user enters a wrong password when logging in, the exception says that something is wrong with logging details (or so it should). Similar situations apply for other operations as well. But having said that, the current implementation does not provide much help with error messages, we need to improve it.
Are we ok to remove all exception throwing?
I don't think this is a good idea. But we'll wait for other opinions.
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
aha... Now I get it. I think we need to verify whether actual Confluence implementation throws exceptions or not (i beleive they don't since the API doesn't indicate of such a thing). If that is so, it's better we remove the Exceptions (so we have more integration). But shouldn't there be any mechanism to report server errors and such (i'm still scratching my head) ? 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.
Yes, but there the problem was, when the return type is specified as void in the RPC, the request doesn't even reach the implementation (i couldn't find out why). I changed it to boolean as a workaround, but still it's not the right thing. In conclusion we need to choose:
1) either we want to implement the Confluence API and we should drop the exceptions
Should we do something about void return types then ? The API has few methods that return void, but we have a problem with void return types in our implementation, think we need to find out why void return types cause a problem. 2) either we don't want and then we shouldn't call it ConfluenceRpcInterface
and then we can throw exceptions...
I personally like this solution since we can add more features of our own in the future, but it's always good to support some standard as well. Thanks for the clear explanation. :) - Asiri Hope this makes it more clear,
Thanks -Vincent
-- You receive this message as a subscriber of the xwiki-dev@objectweb.orgmailing 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 and sorry for the delayed response, On 7/24/07, Asiri Rathnayake <asiri.rathnayake@gmail.com> wrote:
Hi Vincent,
On 7/24/07, Vincent Massol <vincent@massol.net> wrote:
Hi Asiri/Tharindu,
On Jul 24, 2007, at 4:33 PM, Asiri Rathnayake wrote:
On 7/24/07, Vincent Massol <vincent@massol.net> wrote:
Hi,
If our goal is to implement the Confluence XMLRPC interface (
http://confluence.atlassian.com/display/DOC/Remote+API+Specification) then it seems to me we shouldn't throw XWikiException in any method in our ConfluenceRpcInterface interface. Several methods instead should return a boolean to indicate success or failure.
Does anyone know why we're throwing them?
I believe the reason is that we should be able to indicate to the user about what went wrong on the server. This is very useful since there may be situations where the user needs some help with. For an example if the user enters a wrong password when logging in, the exception says that something is wrong with logging details (or so it should). Similar situations apply for other operations as well. But having said that, the current implementation does not provide much help with error messages, we need to improve it.
Are we ok to remove all exception throwing?
I don't think this is a good idea. But we'll wait for other opinions.
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
aha... Now I get it. I think we need to verify whether actual Confluence implementation throws exceptions or not (i beleive they don't since the API doesn't indicate of such a thing). If that is so, it's better we remove the Exceptions (so we have more integration). But shouldn't there be any mechanism to report server errors and such (i'm still scratching my head) ?
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).
From http://ws.apache.org/xmlrpc/advanced.html: "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."
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.
Yes, but there the problem was, when the return type is specified as void in the RPC, the request doesn't even reach the implementation (i couldn't find out why). I changed it to boolean as a workaround, but still it's not the right thing.
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.
In conclusion we need to choose: 1) either we want to implement the Confluence API and we should drop the
exceptions
Should we do something about void return types then ? The API has few methods that return void, but we have a problem with void return types in our implementation, think we need to find out why void return types cause a problem.
[snip] Please name the methods which caused you trouble and I'll look into it. Regards, Catalin
Hi Catalin, Many Many Thanks to you. I really wanted to dig into these details but couldn't find a time for it. On 8/10/07, Catalin Hritcu <catalin.hritcu@gmail.com> wrote:
Hi and sorry for the delayed response,
On 7/24/07, Asiri Rathnayake <asiri.rathnayake@gmail.com> wrote:
Hi Vincent,
On 7/24/07, Vincent Massol <vincent@massol.net> wrote:
Hi Asiri/Tharindu,
On Jul 24, 2007, at 4:33 PM, Asiri Rathnayake wrote:
On 7/24/07, Vincent Massol <vincent@massol.net> wrote:
Hi,
If our goal is to implement the Confluence XMLRPC interface (
http://confluence.atlassian.com/display/DOC/Remote+API+Specification) then it seems to me we shouldn't throw XWikiException in any method in our ConfluenceRpcInterface interface. Several methods instead should return a boolean to indicate success or failure.
Does anyone know why we're throwing them?
I believe the reason is that we should be able to indicate to the user about what went wrong on the server. This is very useful since there may be situations where the user needs some help with. For an example if the user enters a wrong password when logging in, the exception says that something is wrong with logging details (or so it should). Similar situations apply for other operations as well. But having said that, the current implementation does not provide much help with error messages, we need to improve it.
Are we ok to remove all exception throwing?
I don't think this is a good idea. But we'll wait for other opinions.
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
aha... Now I get it. I think we need to verify whether actual Confluence implementation throws exceptions or not (i beleive they don't since the API doesn't indicate of such a thing). If that is so, it's better we remove the Exceptions (so we have more integration). But shouldn't there be any mechanism to report server errors and such (i'm still scratching my head) ?
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).
I think we should also throw the generic java.lang.Exception type exceptions along with some error code and a meaningful error message and avoid XWiki specific exceptions (i think it's obvious). 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).
From http://ws.apache.org/xmlrpc/advanced.html: "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."
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.
Yes, but there the problem was, when the return type is specified as void in the RPC, the request doesn't even reach the implementation (i couldn't find out why). I changed it to boolean as a workaround, but still it's not the right thing.
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.
Voila...
In conclusion we need to choose: 1) either we want to implement the Confluence API and we should drop
the
exceptions
Should we do something about void return types then ? The API has few methods that return void, but we have a problem with void return types in our implementation, think we need to find out why void return types cause a problem.
[snip]
Please name the methods which caused you trouble and I'll look into it.
Well, everything mentioned in XMLRPC API with a void return type will cause a problem. But I think i have replaced the only one such method (delete page, i think) currently implemented in XWiki. Anyway, as we go on implementing more of the API, we'll need to have a boolean (or something suitable) as the return type for those conflicting methods in API. Thanks a lot. - Asiri Regards,
Catalin
-- You receive this message as a subscriber of the xwiki-dev@objectweb.orgmailing 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 Asiri, On 8/10/07, Asiri Rathnayake <asiri.rathnayake@gmail.com> wrote: [snip]
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).
I think we should also throw the generic java.lang.Exception type exceptions along with some error code and a meaningful error message and avoid XWiki specific exceptions (i think it's obvious).
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]
Please name the methods which caused you trouble and I'll look into it.
Well, everything mentioned in XMLRPC API with a void return type will cause a problem. But I think i have replaced the only one such method (delete page, i think) currently implemented in XWiki. Anyway, as we go on implementing more of the API, we'll need to have a boolean (or something suitable) as the return type for those conflicting methods in API.
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 again Asiri, On 8/10/07, Catalin Hritcu <catalin.hritcu@gmail.com> wrote:
Hi Asiri,
On 8/10/07, Asiri Rathnayake <asiri.rathnayake@gmail.com> wrote: [snip]
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).
I think we should also throw the generic java.lang.Exception type exceptions along with some error code and a meaningful error message and avoid XWiki specific exceptions (i think it's obvious).
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]
Please name the methods which caused you trouble and I'll look into it.
Well, everything mentioned in XMLRPC API with a void return type will cause a problem. But I think i have replaced the only one such method (delete page, i think) currently implemented in XWiki. Anyway, as we go on implementing more of the API, we'll need to have a boolean (or something suitable) as the return type for those conflicting methods in API.
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.
The Confluence Remote API specification is just outdated here. I tested and Confluence does return true even from the methods they document as returning void. So we will just do the same. I also found the reason for the problems you (and many others) had with the methods returning void. Void return values are not supported by the XML-RPC specification, and Apache XML-RPC respects this by default. You can set it to return void values like null values, but I think it's wiser to stay away from this extension. Returning true will do. Regards, Catalin
Hi Catalin, On 8/10/07, Catalin Hritcu <catalin.hritcu@gmail.com> wrote:
Hi again Asiri,
On 8/10/07, Catalin Hritcu <catalin.hritcu@gmail.com> wrote:
Hi Asiri,
On 8/10/07, Asiri Rathnayake <asiri.rathnayake@gmail.com> wrote: [snip]
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).
I think we should also throw the generic java.lang.Exception type exceptions along with some error code and a meaningful error message and avoid XWiki specific exceptions (i think it's obvious).
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]
Please name the methods which caused you trouble and I'll look into it.
Well, everything mentioned in XMLRPC API with a void return type will cause a problem. But I think i have replaced the only one such method (delete page, i think) currently implemented in XWiki. Anyway, as we go on implementing more of the API, we'll need to have a boolean (or something suitable) as the return type for those conflicting methods in API.
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.
The Confluence Remote API specification is just outdated here. I tested and Confluence does return true even from the methods they document as returning void. So we will just do the same.
I also found the reason for the problems you (and many others) had with the methods returning void. Void return values are not supported by the XML-RPC specification, and Apache XML-RPC respects this by default. You can set it to return void values like null values, but I think it's wiser to stay away from this extension. Returning true will do.
Many thanks for finding this. Regards, - Asiri Regards,
Catalin
-- You receive this message as a subscriber of the xwiki-dev@objectweb.orgmailing 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
On Aug 10, 2007, at 9:55 AM, Catalin Hritcu wrote:
Hi Asiri,
On 8/10/07, Asiri Rathnayake <asiri.rathnayake@gmail.com> wrote: [snip]
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).
I think we should also throw the generic java.lang.Exception type exceptions along with some error code and a meaningful error message and avoid XWiki specific exceptions (i think it's obvious).
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.
+1000. I hate this so much... We definitely need to do proper exception handling in 1.2.
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?
You said this is transparent for client code so yes I'd go with a XWikiRemoteException or something. If it's not transparent then we need to think more. Anyway are exceptions serialized in XMLRPC? [snip] -Vincent
On Aug 9, 2007, at 9:20 PM, Catalin Hritcu wrote: [snip]
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? [snip]
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... [snip] Thanks Catalin for looking into this -Vincent
Hi Vincent, On 8/10/07, Vincent Massol <vincent@massol.net> wrote:
On Aug 9, 2007, at 9:20 PM, Catalin Hritcu wrote:
[snip]
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.
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.
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]
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...
Sure, I will do that. Regards, Catalin
Hi, There is something i need to add. On 8/10/07, Catalin Hritcu <catalin.hritcu@gmail.com> wrote:
Hi Vincent,
On 8/10/07, Vincent Massol <vincent@massol.net> wrote:
On Aug 9, 2007, at 9:20 PM, Catalin Hritcu wrote:
[snip]
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.
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.
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.
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.
[snip]
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...
Sure, I will do that.
Regards, Catalin
Regards, Catalin
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@gmail.com> wrote:
Hi Vincent,
On 8/10/07, Vincent Massol <vincent@massol.net> wrote:
On Aug 9, 2007, at 9:20 PM, Catalin Hritcu wrote:
[snip]
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.
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.
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.
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.
[snip]
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...
Sure, I will do that.
Regards, Catalin
Regards, Catalin
-- You receive this message as a subscriber of the xwiki- dev@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
Hello, On 7/24/07, Vincent Massol <vincent@massol.net> wrote: [snip]
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... [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
On Jul 25, 2007, at 10:51 AM, Catalin Hritcu wrote:
Hello,
On 7/24/07, Vincent Massol <vincent@massol.net> wrote: [snip]
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... [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?
I see some advantages but not really drawbacks... * They have already fleshed out an API so what's the point of creating a completely different one? Let's benefit from their efforts * Better for our users as it's more likely they'll know the Confluence XMLRPC API rather than some obscure one we invent * We could add APIs to their interface (for XWiki's extended features) without breaking the fact that we implement the Confluence API * I haven't really searched for nice confluence tools using the XMLRPC API but I'm 100% sure we'll gain from this (a pity TimTam is using their SOAP API): - Here are some scripts: http://confluence.atlassian.com/label/ CONFEXT/xml-rpc - http://swizzle.codehaus.org/Swizzle+Confluence. This is really great for us and actually would be a good way to test that we do implement the Confluence API. I can tell you I know people who are going to love it when I break to them that they can use swizzle to control XWiki remotely... ;) But we need to finish our compliance with the Confluence API first. XEclipse will not support Confluence AFAIK and couldn't as we'll need to add XWiki-specific features. I'd be against going away from the Confluence API as I can only see disadvantages right now. We can work around any issue we have with their API and still keep compatibility IMO. Thanks -Vincent
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@massol.net> wrote: [snip]
XEclipse will not support Confluence AFAIK and couldn't as we'll need to add XWiki-specific features.
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
On Jul 25, 2007, at 12:07 PM, Catalin Hritcu wrote:
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@massol.net> wrote: [snip]
XEclipse will not support Confluence AFAIK and couldn't as we'll need to add XWiki-specific features.
What about "gracefully degrading" the functionality if the xwiki-only features are not present, but continuing to work with any confluence-interface-conform implementation ?
Maybe. But I don't think this is a priority. Let's first implement something that works :) Thanks -Vincent
Hi Vincent, On 7/24/07, Vincent Massol <vincent@massol.net> wrote:
Hi, If our goal is to implement the Confluence XMLRPC interface ( http://confluence.atlassian.com/display/DOC/Remote+API+Specification) then it seems to me we shouldn't throw XWikiException in any method in our ConfluenceRpcInterface interface. Several methods instead should return a boolean to indicate success or failure.
Does anyone know why we're throwing them?
Are we ok to remove all exception throwing?
I think it's better we keep those exceptions. At the moment they don't throw much informative exceptions but we could make them do so and let the RPC invoker know what went wrong. For an example, if the getSpaces() call have a problem, there would be no other way of identifying it from the client side, client will only get an empty list (of spaces), which is not correct. Any other ideas ? Thanks. - Tharindu Thanks
-Vincent
-- You receive this message as a subscriber of the xwiki-dev@objectweb.orgmailing 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
On Jul 24, 2007, at 4:50 PM, tharindu jayasuriya wrote:
Hi Vincent,
On 7/24/07, Vincent Massol <vincent@massol.net> wrote: Hi,
If our goal is to implement the Confluence XMLRPC interface ( http://confluence.atlassian.com/display/DOC/Remote+API +Specification) then it seems to me we shouldn't throw XWikiException in any method in our ConfluenceRpcInterface interface. Several methods instead should return a boolean to indicate success or failure.
Does anyone know why we're throwing them?
Are we ok to remove all exception throwing?
I think it's better we keep those exceptions. At the moment they don't throw much informative exceptions but we could make them do so and let the RPC invoker know what went wrong. For an example, if the getSpaces() call have a problem, there would be no other way of identifying it from the client side, client will only get an empty list (of spaces), which is not correct. Any other ideas ?
Yes, see the email I just sent in reply to Asiri's. Thanks -Vincent
participants (4)
-
Asiri Rathnayake -
Catalin Hritcu -
tharindu jayasuriya -
Vincent Massol