Recent changes to feature-requests

Provide OSGi bundle information in MANIFEST.MF

fkal — Thu, 30 Aug 2012 07:38:41 -0000

In order to be able to use the library in an OSGi environment, it must provide OSGi bundle metadata in MANIFEST.MF.
I added the required metadata into build.xml (see attached patch file). Note that I also increased the version to 1.1.2 - you might want to change that...

Introspection loop bug

Anonymous — Wed, 10 Nov 2010 14:11:44 -0000

If an object being introspected contains a reference to itself, the IntrospectingSerializer causes a StackTraceOverflow. The attached patch avoids Introspecting on objects references to itself.

XmlRpcProxy with async

Anonymous — Thu, 23 Sep 2010 21:00:13 -0000

There currently appears to be no way to make an asynchronous call throgh the XmlRpcProxy class.

Preapre redstone XMLRPC for use with any framework

bodziak — Fri, 20 Oct 2006 12:44:52 -0000

Please evaluate the following suggestion with can
enable to use XML-RPC in any framework including e.g
Struts

The idea is :

1) Create Intercepting Filter for web application
which will be able to distinguish if post is XML-RPC
message or usual post

2) if it is XML-RPC post then it will de-serialize
message to Java Object and populate HttpRequest with
the Method name and parameter object. Additionally a
flag indicating that it is XML-RPC request will be
added to HttpRequest object

3) Call doFilter to continue filter chain. This will
allow invoking any kind of servlet to process
request e.g. StrutsActionServelet

4) this will be programer to check HttpRequest for
XMLRPC flag and write action code accordingly

5) When the response prepared by the servlet will be
ready then instead of generation JSP or JSF pages that
produce HTML repose the filter will iterate for
attributes (objects) stored in HttpRequest and
HttpResponse (e.g. It will look for attributes
prefixed ‘XMLRPC:’ ) and the serialize it to XMLRPC or
JSON response and send the message to client

This requires to write the Intercepting Filter and
some refactoring of redstone.xmlrpc package
structure. I think of moving serialization and
serialization classes to new package like of
redstone.xmlrpc.core and the moving servlet ,
xmlrpc server, and method invocation classes to
redstone.xmlrpc.server. In this case
redstone.xmlrpc.core could be packaged to separate JAR
file any used with any framework

Please let me konow what do you thik about this idea

Add Trace.HTTP

Douglas Squirrel — Fri, 27 Feb 2004 16:55:37 -0000

It would be nice to get a log trace of all the HTTP
requests and responses generated by the library. I wrote
my own code to do this and would be happy to share.

Add support for shutting down an XmlRpcServer.

Greger Ohlson — Wed, 04 Feb 2004 01:00:17 -0000

There should be support for shutting down an
XmlRpcServer, including the server socket listening for
inbound XML-RPC messages.

Change session id to a more unique value

Jeff Edrington — Wed, 19 Dec 2001 18:40:07 -0000

When the SessionInvocationProcessor is used, it
currently tracks a session by the callerIp. This is not
unique enough since my application can have many client
instances from the same IP. Can the remote port be
added to the callerIp to make a more unique session id.
I think this would be a simple addition since it would
only require that the getPort() call be added to the
getInetAddress() call in the XmlRpcServer() method.
This will allow several sessions to exist from the same
originating IP.

Thanks.

fault responses

Anonymous — Mon, 22 Oct 2001 09:17:01 -0000

It would be nice that an InvocationHandler could send
a failed response with is own faulCode and faultString.

Now only XmlRpcServer generates failed responses and
always with a faultCode of -1.