InitializationHandler (vs InstantiationHandler)

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

Hi!

After some work I managed to get 3.0b1 up and running just fine.
However, I have a question about / some input on the inner-workings of
ReflectiveXmlRpcHandler that I saw when I checked the code.

I have a state-less instance, but it needs to be initalized with some
objects initally. This might not be state-less in a technical term,
but it is something that I find useful (and hopefully others as well).
In my case the instance needs access to the underlying data storage.

I don't want the instance to be created over-and-over again
which seems to be the case if I use the InitializationHandler:

private Object getInstance(XmlRpcRequest pRequest) throws
XmlRpcException {
final InitializationHandler ih =
mapping.getInitializationHandler();
if (ih == null) {
return theInstance == null ? newInstance() : theInstance;
} else {
final Object instance = newInstance();
ih.init(pRequest, instance);
return instance;
}
}

The problem, as I see it, is that just because the InitializationHandler
exists a new instance is created each time. 
Are pInstanceIsStateless and InitializationHandler really meant to be mutual
exclusive? 


A) 

If not, then I propose that an easy fix would be to change the constructor
so that the InitializationHandler is run. 
Hence, change the constructur from 

theInstance ? pInstanceIsStateless ? newInstance() : null; 

to 
theInstance ? pInstanceIsStateless ? this.getInstance() : null; 

B) 

If they are mutual exclusive I propose a
instantiationHandler/ConstructorHandler
This handler will then, if it exists (!= null) in the
ReflectiveXmlRpcHandler, instantiate the class
and allows for a non-default constructor to be run when the instance is
created. 
It might only happen once (if pInstanceIsStateless == true), whileas the
InitializationHandler (if it exists) would be run everytime getInstance
is called.


I gladly provide a patch for either solution if you find it interesting.
Will it be able to make the 3.0 final then?

Regards,
Jimisola
-- 
View this message in context: http://www.nabble.com/InitializationHandler-%28vs-InstantiationHandler%29-tf1963850.html#a5388986
Sent from the Apache Xml-RPC - Dev forum 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: InitializationHandler (vs InstantiationHandler)

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

Jochen Wiedmann wrote:
> 
>> Depends on the patch. ;-)
> 
>> I understand the use case and I definitely would want it to be
>> supported. I am currently just unsure, whether this isn't already
>> possible, but I assume you have checked sufficiently.
> 

Jochen,

B) 
I am slowly getting acquainted with your source code. Going through it again
I realized that my first suggestion (changing the constructor) won't work.
The InitializationHandler is not run in the constructor. Hence, an
InstantiationHandler in needed. It will be called whenever a new instance is
to be created.

C)
I also noticed that the behaviour of getInstance is not what I would expect
(there might be a perfectly legal reason) when it comes down to how the
InitializationHandler affects the method.
Whenever there is an InitializationHandler set a new instance is created
(see below)!
The InitializationHandler shouldn't affect this, this is what the initial
pInstanceIsStateless controls.

If you agree I'll try to provide a patch for C) and B) (reflection work will
take a little more time) asap, so that it makes it into 3.0.

    private Object getInstance(XmlRpcRequest pRequest) throws
XmlRpcException {
        final InitializationHandler ih = mapping.getInitializationHandler();
        if (ih == null) {
            return theInstance == null ? newInstance() : theInstance;
        } else {
            final Object instance = newInstance();
            ih.init(pRequest, instance);
            return instance;
        }
    } 

Regards,
Jimisola
-- 
View this message in context: http://www.nabble.com/InitializationHandler-%28vs-InstantiationHandler%29-tf1963850.html#a5403734
Sent from the Apache Xml-RPC - Dev forum 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: InitializationHandler (vs InstantiationHandler)

[Jochen Wiedmann <jo...@gmail.com>]

On 7/19/06, Jimisola Laursen <li...@jimisola.com> wrote:

> I gladly provide a patch for either solution if you find it interesting.
> Will it be able to make the 3.0 final then?

Depends on the patch. ;-)

I understand the use case and I definitely would want it to be
supported. I am currently just unsure, whether this isn't already
possible, but I assume you have checked sufficiently.

Jochen

-- 
Whenever you find yourself on the side of the
majority, it is time to pause and reflect.
(Mark Twain)

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