hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stolbikov, Igor" <istolbi...@ineousa.com>
Subject RE: database supplied configurations
Date Thu, 07 Oct 2004 15:39:50 GMT
Thank you for your rapid reply. 

There are few important reasons to keep configuration in the database:
a) Be able to replicate any changes to configuration across multiple hosts.
File based configurations are just not very good for it.

b) Be able to modify some configuration parameters through the Centralized
Administration tools/GUI. Having Admin GUI to talk with database is straight
forward. 

c) Per say we don't talk to database directly to get configuration. We use
special Central Configuration Server that is responsible for all
configuration updates, reads, and services notifications that forces
services to restart when configuration change. 

d) We have to use Central Configuration as we replacing only portion of
existing product and some configuration is shared. 

e) Fault-tolerance requirements. We use Oracle Database and database
replication for all configuration data.  

We consider configuration to be not static, but not dynamic. Something
between.
Is tcp/ip port for listening service configuration? 
It is not very dynamic but not fully static. Administrator might want to
change it.  
Another example: if depending from user set up I want to replace one service
implementation to another, is it still configuration? 
I am not applying that configuration can be changed often. It is still be
very static. Administrator might want to change may be once a day or once a
week.

For our product it is very critical questions. 

That brings me to question, on how I can write custom ModuleDescriptor that
does custom configuration retrieval logic? Do you have any examples of doing
this for another ModuleDescriptor providers?   
Is custom "Registry" more practical solution vs custom ModuleDescriptor?

Thank you very much again for your time.

Igor



-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com] 
Sent: Thursday, October 07, 2004 10:29 AM
To: hivemind-user@jakarta.apache.org
Subject: Re: database supplied configurations

My thoughts are that HiveMind exists to complement the *static* nature
of your application.

When you start talkling about bringing in data from a database, that's
dynamic.

It would be nice to bring in data from such locations, and Knut's
recent work would support that. He made it significantly easier to
obtain ModuleDescriptors for other locations; XML files on the
classpath is now merely the default.

Ideally, it would be nice if you could define your database access
code inside HiveMind, but that is not practical; the lifecycle of
HiveMind services and configurations simply doesn't allow for that.

In theory, you could build a "bootstrap" Registry, and have it
construct a second "runtime" Registry.




On Thu, 7 Oct 2004 10:21:09 -0400, Stolbikov, Igor
<istolbikov@ineousa.com> wrote:
>  
>  
> 
> Hi everybody. 
> 
>   
> 
> I am trying to evaluate HiveMind to use as foundation for redesign efforts
> of one of our products. 
> 
> One of the major requirements for it is ability to support multiple
database
> stored configurations.
>    
> 
> In this respect I have few questions to the HiveMind developers: Did you
> ever consider supplying services that will feed Configurations from
external
> sources, like database to extend Configuration Points?
>  What were your design decisions in this case? If no, what do you think
will
> be the best way to implement such services? How they can be will plugged
> into HiveMind framework? Shall we just write our own Registry service or
you
> can suggest more elegant solutions?  Thank you very much.  Igor  
>  
>  
> 
>   


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


Mime
View raw message