Re: [carol] Carol configuration for handling all features request

[Florent BENOIT <Florent.BENOIT@xxxxxxxxxxxxx>]

Bordet, Simone wrote:

> > Maybe we can split the Configuration concept into 2 parts :
> > the Protocol and the Configuration.
> > the Protocol will be dealing with some kind of static 
> > configuration that is linked to a protocol (jrmp, iiop, 
> > jeremie, ...) such as initialContextFactory classname, 
> > PortableRemoteObjectDelegate, ...
> >    
>
> I was under the impression that carol can support multiple protocols at 
> once, and that this was the reason to have one config file for all protocols.
>
>  
Yes it support multiple protocols at once but only providerurl by 
protocol. The aim is to have a 1 - n relation between one protocol and n 
provider url.
For example allowing carol to start 1,2,3,.. JRMP registries. For now 
this is impossible.

But if we want to do JRMP, we don't have to set the MultiProdelegate 
class, the JRMP initialContextfactory (defaults value).
We only want to define the URL to have (url + port).

> > Protocol are, in my mind, somehow static : loaded at startup, 
> > and Configurations are attached to it after. No need to add 
> > programmatically a new protocol.
> > and the Configuration will be a personnality of a given 
> > Protocol : it may add some "instance" property such as 
> > provider URL, or any other property that may differ from a 
> > Configuration to another.
> > That's the dynamic part that will permit to have 2 JRMP 
> > Configurations (will share the same Protocol), the first one 
> > pointing to a registry A and the second one to the registry 
> > B. (this is not actually feasible)
> >    
>
> Really ? 
> I would be surprised if not.
> Can I specify the provider URL for JNDI lookup to InitialContext.lookup() and get stubs from 2 different naming servers ?
> Have I misunderstood your point ?
>
> InitialContext ctx = new InitialContext();
> ctx.lookup("rmi://host/server1");
> ctx.lookup("iiop://anotherhost/server2");
>
>  
>
> What above is carol-independent.
>
> InitialContext ctx = new InitialContext();
> Configurations.setCurrent("rmi"); // or whatever else
> ctx.lookup("rmi://host/server1");
> Configurations.setCurrent("iiop"); // or whatever else
> ctx.lookup("iiop://anotherhost/server2");
>
> This is not carol-independent.
>
> However, my primary concern wasn't about JNDI, but about export of remote 
> object, but again I'm no carol expert.
>
>  

In carol the aim is to avoid to put URL into InitialContext(), lookup() 
or whatever.
So there is no link to a protocol.
So I think the problem with your understanding of Guillaume and you 
comes from here.

Yes by specifying PROVIDER_URL in the code allow to specify the protocol 
and registry to use but this could be avoided by using Carol.


Someone give you the following code :

InitialContext ctx = new InitialContext();

ctx.lookup("myObject");


If you do a container using Carol, the code could use iiop, jrmp, etc. 
without specifying in this code the protocol used.


But for now there is a problem as one protocol = one provider url
So if we set JRMP if cannot handle registry jrmp 1 and registry jrmp 2.

With config we could do (simplified way)

Config c1 = Repository.newConfig("jrmp") (it will return a preconfigured 
object for jrmp protocol)
c1.setProperty(url, "jrmp://toto:1234");
Repository.setCurrent(c);

InitialContext ctx = new InitialContext();

ctx.lookup("myObject");


Config c2 = Repository.newConfig("jrmp")
c2.setProperty(url, "jrmp://titi:2345");
Repository.setCurrent(c2);

InitialContext ctx = new InitialContext();

ctx.lookup("myObject");


And we will have the same code which has use two different registries.


Note that it can be done with :

InitialContext ctx = new InitialContext("jrmp://titi:2345");

ctx.lookup("myObject");

InitialContext ctx = new InitialContext("jrmp://toto:1234");

ctx.lookup("myObject");


But in this case the code has is linked to a protocol, in the first way, 
this is the container which do the things

Florent.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature