Menu
▾
▴
#5 Preapre redstone XMLRPC for use with any framework
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
Logged In: YES
user_id=91348
Hi!
A ServletFilter sounds like a nice idea. However, is it
really necessary to modify the existing code to achieve
this? Wouldn't it be possible just to complement the
XmlRpcServlet with an XmlRpcServletFilter that does what
you request? This way, the existing code can remain
unchanged. Regarding the JAR packaging it is easy to add
new targets in the build file to build and package just
what you want. You wouldn't get a core package though, but
I think the existing package structure would be acceptable.
The new JAR you mention would then include
redstone.xmlrpc.XmlRpcServletFilter and the
redstone.xmlrpc.serializers package.
And regarding the XMLRPC prefix I don't think this is
required since an XML-RPC invocation only can return one
value as the result. It would make sense to put this value
under a prefixed attribute key like
"redstone.xmlrpc.response".
The arguments to be read by the "legacy framework" is
another matter though since method parameters are unnamed
in XML-RPC. The XmlRpcServletFilter could put these in
attributes named "1", "2", "3", and so on. Or
redstone.xmlrpc.request.1, 2, 3, ...
Anyhow... the addition feels quite doable. Although since
the payload is XML and not a multipart message with form
parameters no other parameter values except the XML-RPC
method invocation arguments will be available to the legacy
controller/servlet.
Just out of curiosity what use-cases have you identified
that the servlet filter will solve?
Cheers,
Greger.
Logged In: YES
user_id=91348
Hi!
A ServletFilter sounds like a nice idea. However, is it
really necessary to modify the existing code to achieve
this? Wouldn't it be possible just to complement the
XmlRpcServlet with an XmlRpcServletFilter that does what
you request? This way, the existing code can remain
unchanged. Regarding the JAR packaging it is easy to add
new targets in the build file to build and package just
what you want. You wouldn't get a core package though, but
I think the existing package structure would be acceptable.
The new JAR you mention would then include
redstone.xmlrpc.XmlRpcServletFilter and the
redstone.xmlrpc.serializers package.
And regarding the XMLRPC prefix I don't think this is
required since an XML-RPC invocation only can return one
value as the result. It would make sense to put this value
under a prefixed attribute key like
"redstone.xmlrpc.response".
The arguments to be read by the "legacy framework" is
another matter though since method parameters are unnamed
in XML-RPC. The XmlRpcServletFilter could put these in
attributes named "1", "2", "3", and so on. Or
redstone.xmlrpc.request.1, 2, 3, ...
Anyhow... the addition feels quite doable. Although since
the payload is XML and not a multipart message with form
parameters no other parameter values except the XML-RPC
method invocation arguments will be available to the legacy
controller/servlet.
Just out of curiosity what use-cases have you identified
that the servlet filter will solve?
Cheers,
Greger.