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

[Guillaume Sauthier <Guillaume.Sauthier@xxxxxxxxxxxxx>]

Hi all

Some random thoughts about the future API :

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, ...
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)

API preview :

// return the Configuration named XX
ConfigurationRepository.getConfiguration(String)

// set the given Configuration as current
ConfigurationRepository.setCurrent(Configuration)

// create a new Configuration that will use the given protocol
// that's more a Factory method, rather than Repository  :)
ConfigurationRepository.newConfiguration(Protocol, String)

// initialize all Protocol + Configurations from a given URL
ConfigurationRepository.init(URL)


// return Configuration unique name
Configuration.getName()
// returns the associated Protocol instance
Configuration.getProtocol()
// getter
Configuration.get(String)
setter
Configuration.put(String, Object)
// remover
Configuration.remove(String)
// load Configuration "personnality"
Configuration.load(URL)

// returns Protocol name
Protocol.getName()
Note : If protocols shouldn't be changed, there should be very minimal 
setter methods

regards
Guillaume

PS : Some comments are inside the text below ..

Bordet, Simone wrote:

> Hi, 
>
>  
>
> > If repository is a factory, it will return empty configuration ? 
> >    
>
> Yes.
>
> // Allow anyone to plugin its own configuration implementation
> Configuration c = Configurations.newConfiguration();
>
> URL url = ...;
> c.load(url);
>
> // Thread local config
> Configurations.setCurrent(c);
>
> // Named configuration
> Configurations.set("foo", c);
>
>  
>
> > configuration with values of carol-default.properties ?
> >    
>
> Yes, that may also be:
>
> // Loads carol-defaults.properties
> // Just a shadow method to help the users.
> Configuration c = Configurations.newDefaultConfiguration();
>  

>  
>
> > Do we have to send arguments to the factory class for 
> > retrieve a configuration object ?
> >    
>
> Not in my idea, but then again you're the carol expert.
>
>  
>
> > Do you have ideas on the factory methods that you want ?
> >    
>
> Only 1/2, see above.
>
>  
>
> > The interface + default implementation seems to be a good 
> > choice. It is up to us to take a good interface :)
> >    
>
> Yes.
> Configuration is an interface.
> I think a Map-style interface (get(String), put(String,Object), 
> remove(String)) for properties, along with load(URL) are the minimum. The 
> less methods, the best, IMHO.
>
> Also, I would not use ResourceBundle to load files: it constraints to .properties, while in the future one may want XML or other fancy formats.
>  

Agree

>  
>
> > > and a configuration class that loads configurations
> > >      
>
> Yes.
>
> Configurations is a concrete class.
> It handles 2 things: 
> 1. creation of a Configuration implementation
> 2. repository for configurations
>
> See above for possible methods.
>
>  
>
> > So it means that a class will take carol.properties file and 
> > call factory for create each configuration present in this file.
> > (a replacement URL could be given instead of taking 
> > carol.properties file with classpath, we can reload a new 
> > configuration later...)
> >    
>
> Here's where my carol knowledge is too small.
>
> I probably would prefer 2 files for 2 configurations:
>
> carol-jrmp.properties
> carol-iiop.properties
>
> carol-<protocol>.properties in general.
>  

Why not.
But in my mind we should distinct protocols and configuration.
carol-<protocol>.properties suits me fine. this file should have all the 
"static" protocol configuration inside

And we can add a carol-<configuration>.properties to store config 
"personnalities"

That may lead to a lot of files...

>  
>
> > Carol should handle only a default config when running in 
> > multi-config mode on client case. (on server, it will call 
> > each configuration) I think that this is to the developer to 
> > explicitely set the config. 
> > Maybe that it is possible without explicitely calls but I 
> > don't see how for now.
> >    
>
> I was thinking that since it is possible to, for example, propagate 
> transactionall contexts, then at a certain point some carol code is hit 
> anyway.
>
> If this code is hit before or after the last point where it is possible to change configuration is beyond my current carol knowledge.
> But interceptors are protocol-independent, no ?
>  

AFAIK, Interceptors are protocol dependent.
We have IIOP interceptor for contexts propagation and another set of 
Interceptors for JRMP :'(

> If that is possible, it would be super-easy for the client, since carol will 
> take care of doing everything right.
>
> Thanks !
>
> Simon
>
>  
>
> ------------------------------------------------------------------------
>
>
>