Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Problem with SharedObject API

Hi Scott.

Google Translator translates this text

But, it brokes code examples formatting and do not translate any termins

Scott Lewis пишет:
> Hi Pavel,
> Thanks for the blogging.  Any chance that we could get your blog
> posting converted to English and made available somehow?  Are there
> Russion to English conversion services that would do the trick?
> Thanks,
> Scott
> Samolisov Pavel wrote:
>> Hello All,
>> Scott, thanks for you reply. It works fine.
>> I had understood SharedObject API and blogged about it
>> (on Russian).
>> Scott Lewis пишет:
>>> Hi Pavel,
>>> Samolisov Pavel wrote:
>>>> Hash: SHA1
>>>> Thanks Scott.
>>>> Tests works fine, my code works too. But I do not understand why this
>>>> code is in TestSharedObject (in method initialize()):
>>>> // This is a replica, so initialize the name from property
>>>> name = (String) getConfig().getProperties().get(NAME_PROPERTY);
>>>> Is this code a deserialization from Config to SharedObject? Why
>>>> name do
>>>> not replicate with SharedObject automaticaly?
>>> This code is only executed on the non-primary copy of the shared
>>> object (i.e. the replicas).  This code (run only on the primary copy),
>>> is responsible for serializing the state of the shared object (in this
>>> case, it's name):
>>>    protected ReplicaSharedObjectDescription getReplicaDescription(ID
>>> receiver) {
>>>        // Put primary state into properties and include in replica
>>> description
>>>        final Map properties = new HashMap();
>>>        properties.put(NAME_PROPERTY, name);
>>>        return new ReplicaSharedObjectDescription(this.getClass(),
>>> getConfig().getSharedObjectID(), getConfig().getHomeContainerID(),
>>> properties);
>>>    }
>>> And then the code you quote above sets the name (for the replicas) to
>>> the value specified by the properties included in the
>>> ReplicaSharedObjectDescription.  The serialization/deserialization of
>>> shared object state is done explicitly rather than as
>>> to give the shared object programmer some control over the
>>> serialization.  I was/have been thinking of adding some implicit
>>> serialization of shared object fields (perhaps through annotations
>>> processing or some such), but for the moment everything is explicitly
>>> done (via properties).
>>>> And another question: Does SharedObject API have any listeners that
>>>> calls when shared object has been added?
>>> Yes, indeed.  An IContainerEvent of sub-type
>>> ISharedObjectActivatedEvent is sent to any/all IContainerListeners
>>> before the shared object is activated, and similarly
>>> ISharedObjectDeactivatedEvent is sent before the shared object is
>>> deactivated.  The shared object itself is also asynchronously notified
>>> as well (the shared object has a message queue and a thread created
>>> for it to process it's messages...and that's how the initialize method
>>> gets called on the replicas).
>>> Scott

Pavel Samolisov

Meet me at:
XMPP/Jabber: samolisov@xxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature

Back to the top