Return-Path: Delivered-To: apmail-jakarta-hivemind-user-archive@www.apache.org Received: (qmail 79830 invoked from network); 7 Oct 2004 15:40:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 7 Oct 2004 15:40:02 -0000 Received: (qmail 98968 invoked by uid 500); 7 Oct 2004 15:40:01 -0000 Delivered-To: apmail-jakarta-hivemind-user-archive@jakarta.apache.org Received: (qmail 98845 invoked by uid 500); 7 Oct 2004 15:40:00 -0000 Mailing-List: contact hivemind-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: hivemind-user@jakarta.apache.org Delivered-To: mailing list hivemind-user@jakarta.apache.org Received: (qmail 98830 invoked by uid 99); 7 Oct 2004 15:40:00 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from [209.58.140.15] (HELO mail-relay4.mirrorimage.net) (209.58.140.15) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 07 Oct 2004 08:39:59 -0700 Received: from triton.int.mirrorimage.net (unknown [172.17.254.26]) by mail-relay4.mirrorimage.net (Postfix) with ESMTP id 9542669275 for ; Thu, 7 Oct 2004 11:39:57 -0400 (EDT) Received: by triton.int.mirrorimage.net with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Oct 2004 11:39:56 -0400 Message-ID: <10AD1EFA9FFF1B46AADA38B7A1BD5EFB02694F@triton.int.mirrorimage.net> From: "Stolbikov, Igor" To: "'hivemind-user@jakarta.apache.org'" Subject: RE: database supplied configurations Date: Thu, 7 Oct 2004 11:39:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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 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