10 Aug
2007
10 Aug
'07
6:56 a.m.
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(a)gmail.com> wrote:
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,
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).
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
Hi Vincent,
On 7/24/07, Vincent Massol <vincent(a)massol.net> wrote:
our
Hi Asiri/Tharindu,
On Jul 24, 2007, at 4:33 PM, Asiri Rathnayake wrote:
On 7/24/07, Vincent Massol <vincent(a)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 ConfluenceRpcInterface interface. Several methods
instead should return
a
boolean to indicate success or failure.
about what
went wrong on the server. This is very useful since there may
be
Does anyone know why we're throwing them?
I believe the reason is that we should be able to indicate to the user 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:
Confluence
- 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 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) ?
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
Voila...
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
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. Catalin
--
You receive this message as a subscriber of the xwiki-dev(a)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