16 Jul
2009
16 Jul
'09
4:36 p.m.
Hi,
We actually have an existing XMLRPC server that we need to integrate
inside XWiki v2.0m1. The only way we achieve this is to modify the
existing code to allow the injection of a XWikiContext object on the
instance created by the default requestProcessor (which does not bind
any object when using the @Requirement annotation).
The other thing is to add an entry inside the /XmlRpcServlet.properties/
representing our service.
Is there any other way to do this ? For example, we could declare our
xml-rpc service class inside the /components.txt/ and let the xml-rpc
server use the component manager to dispatch calls...
Cheers,
Francois D.
16 Jul
16 Jul
8:44 p.m.
On Jul 16, 2009, at 4:36 PM, François Dénommée wrote:
Hi,
We actually have an existing XMLRPC server that we need to integrate
inside XWiki v2.0m1. The only way we achieve this is to modify the
existing code to allow the injection of a XWikiContext object on the
instance created by the default requestProcessor (which does not bind
any object when using the @Requirement annotation).
The other thing is to add an entry inside the /
XmlRpcServlet.properties/
representing our service.
Is there any other way to do this ? For example, we could declare our
xml-rpc service class inside the /components.txt/ and let the xml-rpc
server use the component manager to dispatch calls...
Hi Francois,
currently the XWiki XMLRPC subsystem is not very modular and it would
be interesting to make it so.
The "core" is in the XWikiXmlRpcServlet and in the
XWikiXmlRpcApiInvocationHandler.
The first, as you hinted, returns a java proxy that uses the
invocation handler to initialize the context before calling the actual
method and free it after the call returns.
Currently you can extend it in two ways:
1) Adding methods to the XWikiXmlRpcApi and XWikiXmlRpcApiImpl (not
very elegant but it's the fastest way)
2) Modify the getRequestProcessor in the XWikiXmlRpcServlet source
code in order to take into account additional interfaces and their
invocation handlers.
Of course all of this is based on the old core that is going to
disappear eventually.
As you hinted an interesting way for extending it is that, instead of
using a fixed interface and implementation (XWikiXmlRpcApi and
XWikiXmlRpcApiImpl) we could lookup them using the component manager.
However, I am not so sure that we could avoid the fact of declaring
them also into XmlRpcServlet.properties. So even with the
"componentized" version we would have two files to modify for
publishing the service (components.txt and XmlRpcServlet.properties).
Of course, as right now XMLRPC is part of the core, the idea is to
componentize the XMLRPC subsystem as well in order to remove any
dependency.
Hope this helps.
-Fabio
5594
days inactive
5594
days old
1 comments
2 participants
participants (2)
-
Fabio Mancinelli -
François Dénommée