List Info

Thread: Created: (XMLRPC-109) Problem initalizing the request processors
Created: (XMLRPC-109) Problem initalizing the request processors
user name
 2006-08-26 14:27:23 
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
         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_initiali
zation

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.setRequestProcessorFactoryF
actory 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.atl
assian.com/software/jira
Resolved: (XMLRPC-109) Problem initalizing the request processors
user name
 2006-08-26 20:13:25 
     [ 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_initiali
zation
> 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.setRequestProcessorFactoryF
actory 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.atl
assian.com/software/jira
Closed: (XMLRPC-109) Problem initalizing the request processors
user name
 2006-10-05 20:58:29 
     [ http://issues.apache.org/jira/browse/XMLRPC-109?page=all
 ]

Jochen Wiedmann closed XMLRPC-109.
----------------------------------


> 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_initiali
zation
> 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.setRequestProcessorFactoryF
actory 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.atl
assian.com/software/jira
[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )