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:
> >...
> >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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
