[ http://issues.apache.org/jira/browse/XMLRPC-109?page=all ]
Jochen Wiedmann resolved XMLRPC-109.
------------------------------------
Fix Version/s: 3.0
Resolution: Fixed
I've been choosing the first alternative.
> Problem initalizing the request processors
> ------------------------------------------
>
> Key: XMLRPC-109
> URL: http://issues.apache.org/jira/browse/XMLRPC-109
> Project: XML-RPC
> Issue Type: Bug
> Components: Source, Website
> Affects Versions: 3.0rc1
> Reporter: Catalin Hritcu
> Fix For: 3.0
>
> Attachments: P2PXWikiXmlRpcServlet.java
>
>
> Tried to implement request processors as described in the very good FAQ entry
> here http://ws.apache.org/xmlrpc/faq.html#handler_initialization
> It didn't work at first, and when debugging I discovered that there is a
> major problem here. First a handler map is loaded from a property file, and
> all the handlers are given default RPFFactories.
> PropertyHandlerMapping mapping = super.newPropertyHandlerMapping(url);
> only later is the new RPFFactory created and assigned to the map.
> mapping.load(Thread.currentThread().getContextClassLoader(), url);
> Well, this only stores it in the map, but does not modify any of the handlers
> the map already contains. Which makes the effort of creating and assigning a
> new factory to the map useless, since the factory won't be used when creating
> new handler instances.
> The javadoc is quite useless here in determining the correct behaviour.
> AbstractReflectiveHandlerMapping.setRequestProcessorFactoryFactory only says
> "Sets the mappings RequestProcessorFactoryFactory." No word about what
> should happen with the handlers that are already in the map.
> Since the correct behaviour is not specified there are probably many ways to
> fix this:
> 1. setRequestProcessorFactoryFactory does not update any handlers (current
> situation). Then specify this in the javadoc and fix the FAQ (see attached
> source for a (less elegant) way to accomplish the same thing).
> 2. setRequestProcessorFactoryFactory updates all the contained handlers.
> 3. The handlers never get out of sync with the map that contains them - they
> just don't duplicate information present in the map.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
