web3 block - lifecycle issues and class design

[Igor Naumov <ig...@hotmail.com>]

I have been using the block web3 for some time and ran into a couple of 
issues.

Most of them are related to the lifecycle of the class - it seems that some 
things are preventing a clean instantiation/disposal of the block classes.

In particular, method Web3DataSourceSelectorImpl.dispose() destroys (through 
=null ) the manager and lock properties. For some reason when an application 
(Cocoon) is restarted (without restarting servlet/J2EE/JVM, e.g. through a 
URL ?cocoon-reload=true), the class (Web3DataSourceSelectorImpl) is not 
completely unloaded, so the private static properties are not 
re-initialized.
That causes a null pointer exception next time the class is used.

So may be the code needs to be changed to init the static properties if they 
are null, or remove the lines that set them to null in the dispose() method.

As a workaround, can anybody suggest a way to "unload" the class? (e.g. when 
restarting Cocoon, or even without it)

_________________________________________________________________
Live Search Maps – find all the local information you need, right when you 
need it. http://maps.live.com/?icid=hmtag2&FORM=MGAC01

Re: web3 block - lifecycle issues and class design

[Joerg Heinicke <jo...@gmx.de>]

Hi Igor,

On 31.03.2007 03:43, Igor Naumov wrote:

> Oh, good, somebody is not only working on it but also checking the mail 
> list :-)

actually I'm not working on or with it. Just checked the Cocoon 
lifecycle aspects.

> Now since I found somebody to complain to :-), here are a couple of 
> other things.
> 
> Method Web3ClientImpl.initClient sets a different repository for 
> essentially every RFC call (or am I missing something?)

The whole processing is indeed done on every call. I don't know about 
the consequences changing this or whether any of those objects are 
reusable or thread safe. Actually I don't know anything about the SAP stuff.

> Default streamer DefaultWeb3StreamerImpl seems to trim white space from 
> the string field values.

Yes, it does.

> I think I saw some reasoning behind it in the SVN comments, but I am 
> still not sure if this is entirely correct.

Not much reasoning in the commit message. It only says "handling null 
values". For non-null values trim() was applied with that commit.

> While it's an SAP habit to discard the trailing whitespace (at least 
> internally), the leading spaces are still preserved.
> So trim() is not completely adequate for the task.
> Any comments on that?

No idea. Maybe there are some specs?

Jörg

Re: web3 block - lifecycle issues and class design

[Igor Naumov <ig...@hotmail.com>]

Joerg Heinicke wrote:
> Oh, somebody is using it :)
Oh, good, somebody is not only working on it but also checking the mail 
list :-)
>> In particular, method Web3DataSourceSelectorImpl.dispose() destroys 
>> (through =null ) the manager and lock properties.
>
> Nulling the lock is indeed wrong, especially since dispose() is called 
> for every instance (though we should have only one due to ThreadSafe). 
> But I can't see why nulling the manager should cause any problem. It 
> should be reinjected via service() on next access to the component.
>

I think you are right about nulling the manager. I probably got confused 
while trying to fix it.
Basically I needed to reset all the connection pools and one way I found 
was to dispose the selector (restarting cocoon is just the simplest way 
to reproduce the issue).
But I had to comment out nulling the lock (and manager for some reason).
It turns out that nulling the manager is indeed harmless.
Thanks for fixing it!

Now since I found somebody to complain to :-), here are a couple of 
other things.

Method Web3ClientImpl.initClient sets a different repository for 
essentially every RFC call (or am I missing something?)
Wouldn't it be a performance drag? I would imagine a more effective way 
would be to use the pool name (since the pool points to the same system 
anyway)?

Default streamer DefaultWeb3StreamerImpl seems to trim white space from 
the string field values.
I think I saw some reasoning behind it in the SVN comments, but I am 
still not sure if this is entirely correct.
While it's an SAP habit to discard the trailing whitespace (at least 
internally), the leading spaces are still preserved.
So trim() is not completely adequate for the task.
Any comments on that?

Re: web3 block - lifecycle issues and class design

[Joerg Heinicke <jo...@gmx.de>]

On 30.03.2007 20:36, Igor Naumov wrote:
> I have been using the block web3 for some time and ran into a couple of 
> issues.

Oh, somebody is using it :)

> Most of them are related to the lifecycle of the class - it seems that 
> some things are preventing a clean instantiation/disposal of the block 
> classes.
> 
> In particular, method Web3DataSourceSelectorImpl.dispose() destroys 
> (through =null ) the manager and lock properties.

Nulling the lock is indeed wrong, especially since dispose() is called 
for every instance (though we should have only one due to ThreadSafe). 
But I can't see why nulling the manager should cause any problem. It 
should be reinjected via service() on next access to the component.

> For some reason when an application (Cocoon) is restarted (without
> restarting servlet/J2EE/JVM, e.g. through a URL ?cocoon-reload=true),
> the class (Web3DataSourceSelectorImpl) is not completely unloaded,
> so the private static properties are not re-initialized.

I guess this only reloads the components but not their classes. Somebody 
else might confirm this.

Thanks for your report. Fixed it in SVN.

Regards
Jörg