I think what you are suggesting, if I understand you right, is to have a way to tie the service and its configuration? If that's what you mean, I think you can still do that by defining your own config schema that takes the service-id as an atribute like the <invoke-factory>. I am still in the process of wrapping my head around Hivemind so I may be wrong, may be Howard can validate.

-Harish

Bill Lear wrote:

On Tuesday, September 16, 2003 at 11:18:33 (-0400) Howard M. Lewis Ship writes:


...
Let's let this percolate for a few days, hear what people are
thinking 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]




Reply via email to