RE: Configuration mechanisms

16 Apr 2004 19:14:30 -0000

Title: Message
You could represent your existing system as a "gateway" service with HiveMind, much like the gateway to EJBs that's already in place.
 
You can construct your own ModuleDescriptors from your existing info.
 
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
http://howardlewisship.com
-----Original Message-----
From: Drew McAuliffe [mailto:[EMAIL PROTECTED]
Sent: Friday, April 16, 2004 2:38 PM
To: [email protected]
Subject: Configuration mechanisms

Does HiveMind provide any other mechanisms for configuration contributions outside of xml? I have a home-grown services registry that I am considering replacing with HiveMind because of its extensibility. One of the important concepts in this (relatively simple) registry is the concept of a configuration provider. And service can have one or more configuration providers, configured in the registry file. Many configuration providers have their own xml files, but others provide data from other sources.
 
For example, one important service is an authorization service, which maintains a cached set of permissions rules and uses them to see if users with a given role can perform a given action. In simple cases, this can be configured with an xml file that maps role principals to allowed operations (optionally supplying an OGNL constraint as well). In other cases, the source of the configuration is actually stored in a database, because users can modify the permissions themselves. In the simple case, I use an xml configuration provider, configured in the registry with the expected filename. In the more complex case, I implement a custom db configuration provider, that knows the names of the necessary tables and can translate them into the interfaces expected by the authorization service. This has db connection information (like a datasource) configured in the registry.
 
From what I can tell, most HiveMind config is based around XML rules, built into modules, that convert XML into the expected objects. Is there support for a more generic configuration contribution, that simple provides a list of configuration elements, but that manages the retrieval of those elements separately?
 
Thanks,
 
Drew

Reply via email to