Bug in RF and libdoc.py for remote libraries? Or behavior by design?
54 views
Skip to first unread message
David
Mar 25, 2011, 11:56:52 PM3/25/11
to robotframework-users
This came up for me as I'm implementing Java remote server and
debugging why stop_remote_server keyword not working and not
documented.
Per the RF remote library spec, get_keyword_documentation() and
get_keyword_arguments() are not required but recommended. Therefore,
there can be implementations that don't implement those or implement
it fully.
Yet, RF when loading remote library, and libdoc will both (naturally)
call get_keyword_documentation against stop_remote_server keyword. If
the documentation method doesn't exist I guess RF just skips/ignores
it. But if it is implemented, it seems RF/libdoc is very strict about
the output returned (must be per the spec, etc.).
In my case, I neglected to implement/account for
get_keyword_documentation and get_keyword_arguments to return
something for stop_remote_server. I only accounted for the keyword in
get_keyword_names and run_keyword. Stop server keyword is special case
as it's part of server implementation and all other keywords are
dynamically fetched from actual library via reflection.
So what ends up happening is that when
get_keyword_documentation(stop_remote_server) is called, server
returns XML-RPC fault code exception rather than the expected string
of some value.
Seems like when this happens RF ignores (not recognize) the keyword
(even though it is in get_keyword_names returned list of keywords),
and likewise libdoc skips documenting the keyword, even though it
could just create an entry for it but with blank argument and
documentation values.
The fix on my side is easy, I'll just have to account for stop server
keyword in the other server interface methods.
But I wanted to bring this up, to know whether RF team considers this
expected behavior by design (if implemented,
get_keyword_documentation() must work to spec and never return an XML-
RPC fault code)? Or whether this is a bug (though maybe low or not low
priority) and I should file one?
debugging why stop_remote_server keyword not working and not
documented.
Per the RF remote library spec, get_keyword_documentation() and
get_keyword_arguments() are not required but recommended. Therefore,
there can be implementations that don't implement those or implement
it fully.
Yet, RF when loading remote library, and libdoc will both (naturally)
call get_keyword_documentation against stop_remote_server keyword. If
the documentation method doesn't exist I guess RF just skips/ignores
it. But if it is implemented, it seems RF/libdoc is very strict about
the output returned (must be per the spec, etc.).
In my case, I neglected to implement/account for
get_keyword_documentation and get_keyword_arguments to return
something for stop_remote_server. I only accounted for the keyword in
get_keyword_names and run_keyword. Stop server keyword is special case
as it's part of server implementation and all other keywords are
dynamically fetched from actual library via reflection.
So what ends up happening is that when
get_keyword_documentation(stop_remote_server) is called, server
returns XML-RPC fault code exception rather than the expected string
of some value.
Seems like when this happens RF ignores (not recognize) the keyword
(even though it is in get_keyword_names returned list of keywords),
and likewise libdoc skips documenting the keyword, even though it
could just create an entry for it but with blank argument and
documentation values.
The fix on my side is easy, I'll just have to account for stop server
keyword in the other server interface methods.
But I wanted to bring this up, to know whether RF team considers this
expected behavior by design (if implemented,
get_keyword_documentation() must work to spec and never return an XML-
RPC fault code)? Or whether this is a bug (though maybe low or not low
priority) and I should file one?
David
Mar 26, 2011, 12:01:59 AM3/26/11
to robotframework-users
> Yet, RF when loading remote library, and libdoc will both (naturally)
> call get_keyword_documentation against stop_remote_server keyword. If
> the documentation method doesn't exist I guess RF just skips/ignores
> it. But if it is implemented, it seems RF/libdoc is very strict about
> the output returned (must be per the spec, etc.).
Clarification, I meant RF/libdoc will naturally (try to) call those
> call get_keyword_documentation against stop_remote_server keyword. If
> the documentation method doesn't exist I guess RF just skips/ignores
> it. But if it is implemented, it seems RF/libdoc is very strict about
> the output returned (must be per the spec, etc.).
methods for stop server keyword, if stop server keyword appears in
list of keywords returned by get_keyword_names.
Pekka Klärck
Mar 27, 2011, 1:57:40 AM3/27/11
to mang...@gmail.com, robotframework-users
2011/3/26 David <mang...@gmail.com>:
>
> But I wanted to bring this up, to know whether RF team considers this
> expected behavior by design (if implemented,
> get_keyword_documentation() must work to spec and never return an XML-
> RPC fault code)? Or whether this is a bug (though maybe low or not low
> priority) and I should file one?
>
> But I wanted to bring this up, to know whether RF team considers this
> expected behavior by design (if implemented,
> get_keyword_documentation() must work to spec and never return an XML-
> RPC fault code)? Or whether this is a bug (though maybe low or not low
> priority) and I should file one?
I consider this a bug either in libdoc.py or in Remote library. Please
submit a bug report and we'll fix it latest for 2.6. If you have
interest you can obviously look at the code yourself to find out where
the fix should be applied.
Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org
Reply all
Reply to author
Forward
0 new messages