Howard M. Lewis Ship wrote:
I think this would be nice, that way the actual service is much cleaner in the event one needs this kind of an assemblage. And it would still let you share a configuration between services. Nice getting better and better!Well, the basic concept of a configuration extension point is that *multiple* modules may contribute to it.
This is part of the Eclipse heritage.
Some examples:
A toolbar, to which many modules may contribute an icon that triggers an action.
* A file name extension map, where different modules may contribute file extensions and services which allow files with the extension to be opened.
* Startup and shutdown classes (as in case study #1).
* HiveMind's innovation is the conversion from XML to Java objects based on rules.
However, the output of that, a list of objects, is often not going to be the end of the story.
To date, I've considered the service to be the ultimate consumer of the list, which may then sort or otherwise convert the elements of the list in a way appropriate to the service. In your case, the Java objects may be KeyValuePair objects that can easily be converted into a Map.
One improvement may be to attach a service to a configuration extension point, the service would be responsible for converting the array into the format needed by the service; for example, converting the KeyValuePair objects into a Map. I'd call this an "assembler service", with an interface
public interface Assembler { public Object assembleConfiguration(List elements); }
This could be specified as an optional attribute of the <schema> and <parameters-schema> elements.
Is anyone else hankering for the Apache MoinMoin wiki to be set up? This could be a Wiki page, rather than an e-mail thread.
-- Howard M. Lewis Ship Creator, Tapestry: Java Web Components http://jakarta.apache.org/tapestry http://jakarta.apache.org/commons/sandbox/hivemind/ http://javatapestry.blogspot.com
-----Original Message-----
From: Bill Lear [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 11:57 AM
To: Jakarta Commons Developers List
Subject: RE: [HiveMind] Suggestion for Bootstrap documentation addition / naming!
On Tuesday, September 16, 2003 at 11:18:33 (-0400) Howard M. Lewis Ship writes:
...are thinking
Let's let this percolate for a few days, hear what people
in terms of intuitive naming.I agree. I think configuration of services is extremely important. It should be very easy and flexible. I was hoping, perhaps naively, to see something that is much simpler than what is currently there (putting aside naming issues). I certainly may misunderstand nearly everything there is to understand about this issue, but my impulse was to write something like this:
<?xml version="1.0"?>
<module id="hivemind.examples" version="1.0.0"> <service id="Adder" interface="hivemind.examples.Adder"> <create-instance class="hivemind.examples.impl.AdderImpl"/> </service>
<configuration service-id="Adder" type="hivemind.ConfigurationMap">
<item key="db.name" value="${user.name}_${db.name}"/>
<item key="db.protocol" value="${db.protocol}"/>
<item key="db.driver" value="${db.driver}"/>
<item key="db.host" value="${db.host}"/>
<item key="db.port" value="${db.port}"/>
<item key="db.user" value="${db.user}"/>
<item key="db.password" value="${db.password}"/>
</configuration>
</module>
Then, in the Java code:
Map config = (Map) registry.getConfiguration("hivemind.examples.Adder");
The idea is that "<configuration>" is totally generic. Here, I've used the default container implementation, specified by the container id "hivemind.ConfigurationMap". This container specifies the XML elements it will accept, the rules for adding them to the container, and the Java class/interface that ultimately is available to the Java programmer. The "<configuration>" element simply gobbles the internal elements, and passes them to the container specified. So, perhaps you need to configure your database with a DBConfiguration bean instead of key/value properties in a map:
<configuration service-id="Adder" type="myorg.DBConfiguration"> <item key="db.name" value="${user.name}_${db.name}"/> <item key="db.protocol" value="${db.protocol}"/> <item key="db.driver" value="${db.driver}"/> <item key="db.host" value="${db.host}"/> <item key="db.port" value="${db.port}"/> <item key="db.user" value="${db.user}"/> <item key="db.password" value="${db.password}"/> </configuration>
DBConfiguration config =
(DBConfiguration) registry.getConfiguration("hivemind.examples.Adder");
You might use this thus:
config.getDBName(); config.getDBProtocol();
or, perhaps more simply:
config.getConnectionURL();
or, if you want to get more involved, use a MySQL DB Configuration container:
<configuration service-id="Adder" type="myorg.MySQLDBConfiguration">
<item key="db.name" value="${user.name}_${db.name}"/>
<item key="db.protocol" value="${db.protocol}"/>
...
</configuration>
MySQLDBConfiguration config =
(MySQLDBConfiguration) registry.getConfiguration("hivemind.examples.Adder");
and then:
Connection conn = config.getConnection();
or whatever...
I may be hopelessly confused as to the intent and/or scope of configuration in hivemind, so please don't hesitate to say so; but, perhaps this opens up more possibilities for configuration components to be developed and shared.
Bill
--------------------------------------------------------------------- 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]
