ws-xmlrpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jimisola Laursen <>
Subject Re: InitParameters are not set (XMLRPC-116)
Date Sat, 11 Nov 2006 15:22:37 GMT


I have fixed this issue and another issue that showed when this was fixed.
The latter issue was due to voidMethodEnabled not being set (here: to true)
using isEnabledForExtension prior to public method being registered. 

Changed XmlRpcServlet.newPropertyHandlerMapping:~180


        mapping.load(Thread.currentThread().getContextClassLoader(), url);


        mapping.load(Thread.currentThread().getContextClassLoader(), url);

I also noticed a slight problem with registerPublicMethods in
AbstractReflectiveHandlerMapping.  registerPublicMethods adds all public
non-static methods that are not declared by the Object class. TypeConverter
will therefore fail.

This introduces a problem when there is a public "init" method for use by an
extended StatelessProcessorFactoryFactory that calls the init method in an
over-loaded getRequestProcessor method.


 1. AgentRPCImpl is the class that I configured in
 2. AgentRPCImpl.init(Agent agent, DataSource dataSource, Config config) is
called from over-loaded getRequestProcessor method in
AgentRPCProcessorFactoryFactory which extends

The init method will be added to the mapper since it public, non-static and
not declared by Object (in is a void method but void methods are allowed
since enableForExtensions is true).

There has to be a way to have method that are public non-static NOT be added
to the handler.

I have three possible solution for this:

 1. use a method annotation to exclude individual methods: not doable since
we don't require Java 1.5
 2. use a prefix on method name for exclusion, such as "__init" or similar:
easy to implement
 3. registerPublicMethods will only add methods that are declared in the
actual class: in my case this would mean that I would have a middle class
for AgentRPCImpl where I add the init method

I don't like that the library would force it users to use a certain class
hierchy and I therefor propose alternative 2. 
What would be a good prefix?

I can provide a patch for the above today if you just give me a go ahead.
I'm actually in desperate need of this asap and it would make it a lot
easier if it was in the  SNAPSHOT.


Jimisola Laursen wrote:
> Jochen,
> I believe that you inserted a bug when you slightly refactored/changed my
> patch for XMLRPC-116.
> In handleInitParameters you call ReflectionUtil.setProperty(server, name,
> value) where server is an XmlRpcServletServer . This class does not have
> any setters for init parameters such as "enabledForExtensions" or
> "contentLengthOptional", so reflection fails. I believe that methods on
> XmlRpcServerConfig are reflection should be used on (this is what I did in
> my patch) and therefore
> ReflectionUtil.setProperty(server, name, value)
> should change to
> ReflectionUtil.setProperty(server.getConfig(), name, value).
> Right? If so, would you mind fixing it and provide a new SNAPSHOT. It
> breaks the whole SNAPSHOT more or less.
> The reason why I found this I got a XmlRpcException ("No such handler: 
> com.example.setX"). Appearently, void methods  aren't compliant with
> standard XML-RPC and since "enableForExtensions" was not set to true
> "voidMethodEnabled" was not set to true (see XmlRpcServlet:180
> "mapping.setVoidMethodEnabled(server.getConfig().isEnabledForExtensions());").
> Regards,
> Jimisola

View this message in context:
Sent from the Apache Xml-RPC - Dev mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message