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]
