Jochen,
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
from
mapping.load(Thread.currentThread().getContextClassLoader(), url);
mapping.setVoidMethodEnabled(server.getConfig().isEnabledForExtensions());
to
mapping.setVoidMethodEnabled(server.getConfig().isEnabledForExtensions());
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.
E.g.
1. AgentRPCImpl is the class that I configured in XmlRpcServlet.properties
2. AgentRPCImpl.init(Agent agent, DataSource dataSource, Config config) is
called from over-loaded getRequestProcessor method in
AgentRPCProcessorFactoryFactory which extends
StatelessProcessorFactoryFactory
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.
Regards,
Jimisola
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:
http://www.nabble.com/InitParameters-are-not-set-%28XMLRPC-116%29-tf2597241.html#a7293580
Sent from the Apache Xml-RPC - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
