a problem about servant locator

[rwxybh]

When dynamiclly creating many proxies, evictor with servant locator is a good idea. but how to pass the parameters to the method ServantLocator::locate(Current , LocalObject) to construct a new servant?

I find that the method ObjectAdapter::createProxy(Identity) doesn't invoke the locate(..) method, utill the xxHelper::checkCast(ObjectPrx, Context) is called.OR the method xxHelper::checkCast(..) invokes the locate method.

Using the paramter context in xxHelper::checkCast(ObjectPrx, Context), I passed parameters to ServantLocator::locate(Current , LocalObject) sucessfully, but I don't know whether it is a good idea?

[benoit]

It looks like your confusing proxies and servants. These are two distinct objects, the former is used by clients to invoke on an Ice object and the latter is used to implement an Ice object. I recommend you to take a closer look at the Ice architecture section in the manual (section 2.2) for detailed explanations on these terms.

The servant locator locate() method is called for each invocation on an Ice object. It's supposed to return the servant implementing the Ice object. When you call checkedCast() on a proxy this implicitly invokes ice_isA() on the Ice object, that's why the servant locator locate() method is called in this case.

I recommend you to take a look at the servant locator documentation in the manual, section 30.6 describes the servant locator interface and section 30.7 "Server Implementation Techniques" shows several implementations of servant locators.

Benoit.

[rwxybh]

Hi,benoit
I'm very sorry!
I mean:
When dynamiclly creating many servants, evictor with servant locator is a good idea.

there is no example in the manual to show how to pass paramters to the ServantLocator::locate method.

my solution:
========================
Using the paramter context in xxHelper::checkCast(ObjectPrx, Context), I passed parameters to ServantLocator::locate(Current , LocalObject) sucessfully
========================

is right or not?

[matthew]

What you are doing does not sound like an appropriate use of the Context parameter. This is supposed to be used for "out of band data" -- namely data about the request, such as the Glacier2 routing parameters.

What parameters do you need to pass to locate?

[rwxybh]

Hi,matthew

In my project,I need to construct servants dynamically, the servants need a particular parameter to initialize. Although the servants are the same class's instance,they have defferent content.

My problem is how to pass the parameters to the locate method?

[marc]

You must use the Ice object's identity for this. If the client provides any information about an Ice object's state other then its identity, you are outside the Ice object model.

[rwxybh]

Hi,marc

To be efficient,on the server, a servant should be constructed only when the client need.So the client only knows a servant, which can create another servant dynamically.The servant to be created dynamically need get a parameter form the creator--the servant which client knows.

The class Identity has only two properties:name(string) and category(string), which can't take the parameter I need.

[marc]

Clients must not be the creator of a servants. Clients must not even be aware of the existence of servants in a server. If they are, you are outside the Ice object model.

A server creates servants for Ice objects. It can create them on demand, using a servant locator. The only information it can use for creating a servant is the object's identity. With the object identity, it can for example look up the Ice object's state in a database, and load such state into a servant.

Perhaps you are confusing servants with Ice objects. Clients can create Ice objects, but this has nothing to do with servants or servant locators. Clients typically do create Ice objects by calling on other Ice objects, which serve as factory. Servants, on the other hand, are completely transparent to clients, and only matter with respect to how a server implements Ice objects. If a client has knowledge of how servants are used in a server, there is no implementation transparency anymore, which is one of the cornerstones of the Ice object model.

[rwxybh]

Hi,Marc
thank you very much!
Clients must not be the creator of a servants. I agree with you.Clients usually get a new proxy by calling the method of another proxy which clients have got. It is corresponding on the server that a servant is created by another servant. Now the servant which is created by another one may want to get some infomation fom it's creator.The information is used for iniaializing the new servant.

There is an example in the manual in 30.6.5 section.on the server-side,the PhoneBook's search method can create a new servant--PhoneEntry, and on the client-side,it is a proxy creates a new proxy.In this example, the servant PhoneEntry only need a name which can be stored in Identity's name property, that is enough for the servant to initialize. But there may be a situation that to create some servant like PhoneEntry need other information, not only the name.

Now i encount the situation mentioned above.

btw: the default servant described in the manual is not thread-safe, right?
There is an object is shared by the servant. To be thread-safe, a lock is needed.

can you tell me how to create a new certs?
The certs in the ice is ecpired.

[mes]

can you tell me how to create a new certs?
The certs in the ice is ecpired.

Thanks for bringing this to our attention. I've posted an archive containing new certificates in this thread.

- Mark

[rwxybh]

mes, you are welcome!

but there is something wrong with the new certs.

test suites reported that the new certs have expired too!

*** running tests in .\test\IceSSl\certificateVerification

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xx


error: sslv3 alert certificate expired!

[mes]

Hi,

You're right. In order to run the IceSSL tests successfully, you'll need to update the certificates in the test/IceSSL/certs directory. From the root directory of the Ice distribution, use these commands:

$ cp certs/cacert.pem test/IceSSL/certs
$ cp certs/c_rsa1024_priv.pem test/IceSSL/certs/goodKey_1.pem
$ cp certs/c_rsa1024_pub.pem test/IceSSL/certs/goodCert_1.pem
$ cp certs/s_rsa1024_priv.pem test/IceSSL/certs/goodKey_2.pem
$ cp certs/s_rsa1024_pub.pem test/IceSSL/certs/goodCert_2.pem

- Mark

[mes]

I've posted a new thread that contains new certificate files for both C++ and Java.

- Mark

[michi]

The servant to be created dynamically need get a parameter form the creator--the servant which client knows.

The class Identity has only two properties:name(string) and category(string), which can't take the parameter I need.

It is physically impossible to access a parameter in locate(). The reason is that the Ice run time cannot unmarshal parameters until after it has located a servant. That is because the servant determines the type of the interface for the request, and the type of the interface determines how to unmarshal the parameters.

The only information you can access inside locate() is the information delivered as part of the current object. To decide which servant to instantiate, you will typically use the object identity. (In rare cases, you might also use the operation name.)

I would recommend against using the Context field--it isn't intended for this purpose.

One option I can think of is that you might be able to use the category field of the object identity to indicate what kind of servant to instantiate. In your server, register a default servant locator and then, inside locate(), look at the category to decide what servant to return from locate().

Cheers,

Michi.

[rwxybh]

Thanks for your reply,michi!

thank you,mes!