Hi Howard, I should say I haven't go through the Hivemind code. I'm not an expert on this. I just think a very simple code like:
DBModuleDescriptor dbmd = new DBModuleDescripter( jdbcConn ); registryBuilder.processModule( dbmd ); // dbmd will retrieve the data directly from DB when called on each method Hope this is not a bad idea. Thanks a lot! Jian On Fri, 8 Oct 2004 07:32:15 -0400, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > Why would you need to subclass ModuleDescriptor? It's a pretty dumb > data-holder; what you need is an implementation of something that > builds the MD from your database data. > > > > > On Thu, 7 Oct 2004 17:38:44 -0700, Jian Wu <[EMAIL PROTECTED]> wrote: > > Hi, > > > > By looking into RegistryBuilder and ModuleDescriptor. it looks like there > > are two approaches to get configuration data from Oracle Database to > > feed into Hivemind: > > > > 1. If you can get JDBC Connection to the Oracle DB at your runtime, > > it seems that it is easier to implement a DB ModuleDescriptor to > > read/write to DB at each method level. > > > > The problem with this approach is right now ModuleDescriptor is > > a final class, you can not extend it with DBModuleDescriptor to > > feed into RegistryBuilder > > > > 2. If you store the hivemind.xml in Oracle DB as BLOB/CLOB or XMLType, > > then, at start-up time, you could download this xml into a local temp > > file > > and let RegistryBuilder to read it. > > > > If RegistryBuilder can overload processModuleResource method to > > take InputStream or InputStreamReader as parameter, it might be > > more flexable. > > > > My 2 cents > > > > Thanks, > > > > Jian > > > > On Thu, 7 Oct 2004 11:39:50 -0400, Stolbikov, Igor > > <[EMAIL PROTECTED]> wrote: > > > 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:[EMAIL PROTECTED] > > > Sent: Thursday, October 07, 2004 10:29 AM > > > To: [email protected] > > > 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 > > > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > http://howardlewisship.com > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
