FAQ
I have a newly developed RESTful interface to an existing server using
C::C::REST. Works nicely -- Catalyst is a very nice tool, and the REST
extensions are very helpful.

The server has existing services that are orthogonal to the RESTful
interface. I don't really wish to RESTify them so I'd like to expose
them as XML-RPC.

Per the tutorial (http://search.cpan.org/~michiel/Catalyst-Plugin-Server-0.24/lib/Catalyst/Plugin/Server/XMLRPC/Tutorial.pod
) I added "Server Serve::XMLRPC" to my "use Catalyst" line.

I now receive this:
-------
RestRPC has a custom request class Catalyst::Plugin::Server::Request,
which is not a Catalyst::Request::REST; see Catalyst::Request::REST
at /Library/Perl/5.8.8/Catalyst/Request/REST.pm line 29.
Compilation failed in require at script/restrpc_server.pl line 55.
-------

I see this in the REST doc:
-------
Note that if you have a custom request class in your application, and
it does
not inherit from C<Catalyst::Request::REST>, your application will
fail with an
error indicating a conflict the first time it tries to use
C<Catalyst::Request::REST>'s functionality. To fix this error, make
sure your
custom request class inherits from C<Catalyst::Request::REST>.
-------
but that doesn't seems like an option here. (These are peers, not
parent/child classes)

Am I missing something obvious?

Is there another way to do XML-RPC + REST?

Seems like I could just handle the POSTs with non-ActionClass('REST')
methods -- but then it becomes "not quite XML-RPC".

Thanks,

Bruce

---
Bruce McKenzie
brucem@dynamicrange.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090408/a12d8cd9/attachment.htm

Search Discussions

  • Hans Dieter Pearcey at Apr 9, 2009 at 1:20 am

    On Wed, Apr 08, 2009 at 06:00:36PM -0700, Bruce McKenzie wrote:
    Note that if you have a custom request class in your application, and it does
    not inherit from C<Catalyst::Request::REST>, your application will fail with an
    error indicating a conflict the first time it tries to use
    C<Catalyst::Request::REST>'s functionality. To fix this error, make sure your
    custom request class inherits from C<Catalyst::Request::REST>.
    -------
    but that doesn't seems like an option here. (These are peers, not parent/child
    classes)

    Am I missing something obvious?
    Doesn't this suck? It should clearly be a request role instead of a request
    class.

    Seriously, I plan to fix this very soon, and I'm sorry it's still biting you.

    hdp.
  • Jay Shirley at Apr 9, 2009 at 1:20 am

    On Thu, Apr 9, 2009 at 10:00 AM, Bruce McKenzie wrote:

    I have a newly developed RESTful interface to an existing server using
    C::C::REST. Works nicely -- Catalyst is a very nice tool, and the REST
    extensions are very helpful.
    The server has existing services that are orthogonal to the RESTful
    interface. I don't really wish to RESTify them so I'd like to expose them as
    XML-RPC.

    Per the tutorial (
    http://search.cpan.org/~michiel/Catalyst-Plugin-Server-0.24/lib/Catalyst/Plugin/Server/XMLRPC/Tutorial.pod<http://search.cpan.org/%7Emichiel/Catalyst-Plugin-Server-0.24/lib/Catalyst/Plugin/Server/XMLRPC/Tutorial.pod> )
    I added "Server Serve::XMLRPC" to my "use Catalyst" line.

    I now receive this:
    -------
    RestRPC has a custom request class Catalyst::Plugin::Server::Request, which
    is not a Catalyst::Request::REST; see Catalyst::Request::REST at
    /Library/Perl/5.8.8/Catalyst/Request/REST.pm line 29.
    Compilation failed in require at script/restrpc_server.pl line 55.
    -------

    I see this in the REST doc:
    -------
    Note that if you have a custom request class in your application, and it
    does
    not inherit from C<Catalyst::Request::REST>, your application will fail
    with an
    error indicating a conflict the first time it tries to use
    C<Catalyst::Request::REST>'s functionality. To fix this error, make sure
    your
    custom request class inherits from C<Catalyst::Request::REST>.
    -------
    but that doesn't seems like an option here. (These are peers, not
    parent/child classes)

    Am I missing something obvious?

    Is there another way to do XML-RPC + REST?

    Seems like I could just handle the POSTs with non-ActionClass('REST')
    methods -- but then it becomes "not quite XML-RPC".

    Thanks,

    Bruce

    ---
    Bruce McKenzie
    brucem@dynamicrange.com




    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    Well, the problem is the two request classes are just fighting and the
    Plugin clobbers it first. The easy solution that I can think of would be to
    create a custom request class that looks like:

    package MyApp::Request::XMLRPCwithREST;

    use strict;
    use warnings;

    use base qw/Catalyst::Request::REST Class::Accessor::Fast/;

    *params = *parameters;

    sub register_server {
    my ($self, $name, $class) = @_;
    return unless ($name && $class);

    $self->mk_accessors($name);
    $self->$name($class);
    }

    Then, after that you just modify the plugins ReqClass to point to yours (in
    MyApp.pm):

    $Catalyst::Plugin::Server::ReqClass = 'MyApp::Request::XMLRpcwithREST';

    This is all just a speculative solution, but I believe it would work for
    you. You're definitely in edge-case territory though.

    -J
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090409/05a38e30/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedApr 9, '09 at 1:00a
activeApr 9, '09 at 1:20a
posts3
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase