InitParameters are not set (XMLRPC-116)

[Jimisola Laursen <li...@jimisola.com>]

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#a7244894
Sent from the Apache Xml-RPC - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org

Re: InitParameters are not set (XMLRPC-116)

[Jimisola Laursen <li...@jimisola.com>]

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: xmlrpc-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: xmlrpc-dev-help@ws.apache.org