You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Bill Lear <ra...@zopyra.com> on 2003/09/16 16:53:35 UTC
[HiveMind] Suggestion for Bootstrap documentation addition
I've just added my first interceptor. Neat stuff. I suggest we add
a section to the example (Bootstrap) to show how to do this and
how to configure the log4j properties (this was a bit confusing
for me).
Here is a sketch:
Debugging the Example Using a Logging Interceptor
Logging interceptors can be used to print out method invocation,
including parameters passed and results returned. Adding a logging
interceptor to a service is easy: add an interceptor clause to your
HiveMind module, and set the log4j debug property on this interceptor
to print out the information when the application is run.
So, for our example, first add a logging interceptor to the HiveMind
module:
<?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.AdderImpl2"/>
<interceptor service-id="hivemind.LoggingInterceptor"/>
</service>
</module>
This interceptor will use the ID of the service within which it is
operating, in this case 'hivemind.examples.Adder'.
Next, set the debug level in the log4j.properties file by
catenating 'log4j.category.' with the service id:
log4j.category.hivemind.examples.Adder=debug
The complete log4j file now looks something like this:
log4j.rootCategory=WARN, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%r %c{1} [%p] %m%n
log4j.category.hivemind.examples.Adder=debug
Now type in 'ant run' from the top-level directory and you should see
the interceptor at work, printing out parameter values on entry, and
the result upon exit:
% ant run
...
[java] 0 Adder [DEBUG] BEGIN add(11, 23)
[java] 5 Adder [DEBUG] END add() [34]
...
You can also get rough execution times for the methods by setting
the pattern for the layout to include millisecond time values:
log4j.appender.A1.layout.ConversionPattern=<%p %d{ISO8601} %c{1}> %m%n
% ant run
...
[java] <DEBUG 2003-09-16 09:46:02,034 Adder> BEGIN add(11, 23)
[java] <DEBUG 2003-09-16 09:46:02,054 Adder> END add() [34]
...
This shows that the Adder add method took about 20 milliseconds to
run. [Q: is this time at all accurate? Does it include any
interceptor overhead, or is it mostly the method invocation?].
In any case, just a suggestion.
Next, I'm going to work on understanding extensions to services.
Not sure I like the terms, "extension" or "extension-point".
Configuring seems much less involved than extending, and HiveMind
extensions seem to be all about configuring. Since I don't fully
understand it, though, once I get through the doc and work through
a few examples, I may change my view.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Suggestion for Bootstrap documentation addition /
naming!
Posted by Harish Krishnaswamy <hk...@comcast.net>.
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: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
Re: [HiveMind] Suggestion for Bootstrap documentation addition /
naming!
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Howard M. Lewis Ship wrote:
>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.
>
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!
>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:rael@zopyra.com]
>>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: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
RE: [HiveMind] Suggestion for Bootstrap documentation addition / naming!
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
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:rael@zopyra.com]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
RE: [HiveMind] Suggestion for Bootstrap documentation addition / naming!
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
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:rael@zopyra.com]
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [HiveMind] Suggestion for Bootstrap documentation addition / naming!
Posted by Bill Lear <ra...@zopyra.com>.
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
RE: [HiveMind] Suggestion for Bootstrap documentation addition / naming!
Posted by Bill Lear <ra...@zopyra.com>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Suggestion for Bootstrap documentation addition /
naming!
Posted by Harish Krishnaswamy <hk...@comcast.net>.
You read my mind, I just asked you about this in my other mail!
But a service is both the core implementation and all its interceptors
put together, right? Extend was always confusing for me right from the
start because of its established presence in OO, I guess.
-Harish
Howard M. Lewis Ship wrote:
>>I am still thinking...
>>
>><service> --> <service-point>
>><extend-service> --> <service>
>><extension-point> --> <configuration-point>
>><extension> --> <configuration>
>>
>>
>>
>>
>
>I like this, except that I would keep <extend-service> as is. I think the typical use of
><extend-service> is to provide additional interceptors to an existing service (even though you can
>occasinally provide a service implementation as well).
>
>Perhaps the more verbose <extend-configuration> would be good too? I think even Bill initially
>missed that all the <extension>'s for an <extension-point> are cumulative ... would
><extend-configuration> make that more clear?
>
>--
>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
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
RE: [HiveMind] Suggestion for Bootstrap documentation addition / naming!
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
>
> I am still thinking...
>
> <service> --> <service-point>
> <extend-service> --> <service>
> <extension-point> --> <configuration-point>
> <extension> --> <configuration>
>
>
I like this, except that I would keep <extend-service> as is. I think the typical use of
<extend-service> is to provide additional interceptors to an existing service (even though you can
occasinally provide a service implementation as well).
Perhaps the more verbose <extend-configuration> would be good too? I think even Bill initially
missed that all the <extension>'s for an <extension-point> are cumulative ... would
<extend-configuration> make that more clear?
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [HiveMind] Suggestion for Bootstrap documentation addition / naming!
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
>
> I am still thinking...
>
> <service> --> <service-point>
> <extend-service> --> <service>
> <extension-point> --> <configuration-point>
> <extension> --> <configuration>
>
>
I like this, except that I would keep <extend-service> as is. I think the typical use of
<extend-service> is to provide additional interceptors to an existing service (even though you can
occasinally provide a service implementation as well).
Perhaps the more verbose <extend-configuration> would be good too? I think even Bill initially
missed that all the <extension>'s for an <extension-point> are cumulative ... would
<extend-configuration> make that more clear?
--
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
Re: [HiveMind] Suggestion for Bootstrap documentation addition /
naming!
Posted by Harish Krishnaswamy <hk...@comcast.net>.
I am still thinking...
<service> --> <service-point>
<extend-service> --> <service>
<extension-point> --> <configuration-point>
<extension> --> <configuration>
-Harish
Howard M. Lewis Ship wrote:
>Hold onto that; I'm getting close to checking in the refactored project, and we can apply the doc
>change as a patch. Good points, very helpful.
>
><extension> and <extension-point> ... if you check the blog, you'll see I changed the names to be
>more consistent with Eclipse, but that's seeming like less and less of a good idea. Refactoring
>this now is painful, but will be worse later.
>
>How about:
>
><extension-point> --> <configuration> and
><extension> --> <contribution>
><extend-service> --> <service-contribution> ?
>
>With similar changes to the API (i.e. Registry.getExtensionPointElements() ->
>getConfigurationElements()) and elsewhere (i.e, set-extension-point -> set-configuration).
>
>Let's let this percolate for a few days, hear what people are thinking in terms of intuitive naming.
>
>--
>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:rael@zopyra.com]
>>Sent: Tuesday, September 16, 2003 10:54 AM
>>To: commons-dev@jakarta.apache.org
>>Subject: [HiveMind] Suggestion for Bootstrap documentation addition
>>
>>
>>I've just added my first interceptor. Neat stuff. I suggest
>>we add a section to the example (Bootstrap) to show how to do
>>this and how to configure the log4j properties (this was a
>>bit confusing for me).
>>
>>Here is a sketch:
>>
>>Debugging the Example Using a Logging Interceptor
>>
>>Logging interceptors can be used to print out method
>>invocation, including parameters passed and results returned.
>> Adding a logging interceptor to a service is easy: add an
>>interceptor clause to your HiveMind module, and set the log4j
>>debug property on this interceptor to print out the
>>information when the application is run.
>>
>>So, for our example, first add a logging interceptor to the HiveMind
>>module:
>>
>><?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.AdderImpl2"/>
>>
>> <interceptor service-id="hivemind.LoggingInterceptor"/>
>> </service>
>></module>
>>
>>This interceptor will use the ID of the service within which
>>it is operating, in this case 'hivemind.examples.Adder'.
>>
>>Next, set the debug level in the log4j.properties file by
>>catenating 'log4j.category.' with the service id:
>>
>>log4j.category.hivemind.examples.Adder=debug
>>
>>The complete log4j file now looks something like this:
>>
>>log4j.rootCategory=WARN, A1
>>log4j.appender.A1=org.apache.log4j.ConsoleAppender
>>log4j.appender.A1.layout=org.apache.log4j.PatternLayout
>>log4j.appender.A1.layout.ConversionPattern=%r %c{1} [%p] %m%n
>>log4j.category.hivemind.examples.Adder=debug
>>
>>
>
>May want a %c pattern, rather than %c{1}, so as to display all of "hivemind.examples.Adder".
>
>
>
>>Now type in 'ant run' from the top-level directory and you
>>should see the interceptor at work, printing out parameter
>>values on entry, and the result upon exit:
>>
>>% ant run
>> ...
>> [java] 0 Adder [DEBUG] BEGIN add(11, 23)
>> [java] 5 Adder [DEBUG] END add() [34]
>> ...
>>
>>You can also get rough execution times for the methods by
>>setting the pattern for the layout to include millisecond time values:
>>
>>log4j.appender.A1.layout.ConversionPattern=<%p %d{ISO8601} %c{1}> %m%n
>>
>>% ant run
>> ...
>> [java] <DEBUG 2003-09-16 09:46:02,034 Adder> BEGIN add(11, 23)
>> [java] <DEBUG 2003-09-16 09:46:02,054 Adder> END add() [34]
>> ...
>>
>>This shows that the Adder add method took about 20
>>milliseconds to run. [Q: is this time at all accurate? Does
>>it include any interceptor overhead, or is it mostly the
>>method invocation?].
>>
>>
>
>Java clock is very innacurate for short periods, less than around 60ms.
>
>
>
>>In any case, just a suggestion.
>>
>>Next, I'm going to work on understanding extensions to
>>services. Not sure I like the terms, "extension" or
>>"extension-point". Configuring seems much less involved than
>>extending, and HiveMind extensions seem to be all about
>>configuring. Since I don't fully understand it, though, once
>>I get through the doc and work through a few examples, I may
>>change my view.
>>
>>
>>Bill
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>
RE: [HiveMind] Suggestion for Bootstrap documentation addition / naming!
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Hold onto that; I'm getting close to checking in the refactored project, and we can apply the doc
change as a patch. Good points, very helpful.
<extension> and <extension-point> ... if you check the blog, you'll see I changed the names to be
more consistent with Eclipse, but that's seeming like less and less of a good idea. Refactoring
this now is painful, but will be worse later.
How about:
<extension-point> --> <configuration> and
<extension> --> <contribution>
<extend-service> --> <service-contribution> ?
With similar changes to the API (i.e. Registry.getExtensionPointElements() ->
getConfigurationElements()) and elsewhere (i.e, set-extension-point -> set-configuration).
Let's let this percolate for a few days, hear what people are thinking in terms of intuitive naming.
--
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:rael@zopyra.com]
> Sent: Tuesday, September 16, 2003 10:54 AM
> To: commons-dev@jakarta.apache.org
> Subject: [HiveMind] Suggestion for Bootstrap documentation addition
>
>
> I've just added my first interceptor. Neat stuff. I suggest
> we add a section to the example (Bootstrap) to show how to do
> this and how to configure the log4j properties (this was a
> bit confusing for me).
>
> Here is a sketch:
>
> Debugging the Example Using a Logging Interceptor
>
> Logging interceptors can be used to print out method
> invocation, including parameters passed and results returned.
> Adding a logging interceptor to a service is easy: add an
> interceptor clause to your HiveMind module, and set the log4j
> debug property on this interceptor to print out the
> information when the application is run.
>
> So, for our example, first add a logging interceptor to the HiveMind
> module:
>
> <?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.AdderImpl2"/>
>
> <interceptor service-id="hivemind.LoggingInterceptor"/>
> </service>
> </module>
>
> This interceptor will use the ID of the service within which
> it is operating, in this case 'hivemind.examples.Adder'.
>
> Next, set the debug level in the log4j.properties file by
> catenating 'log4j.category.' with the service id:
>
> log4j.category.hivemind.examples.Adder=debug
>
> The complete log4j file now looks something like this:
>
> log4j.rootCategory=WARN, A1
> log4j.appender.A1=org.apache.log4j.ConsoleAppender
> log4j.appender.A1.layout=org.apache.log4j.PatternLayout
> log4j.appender.A1.layout.ConversionPattern=%r %c{1} [%p] %m%n
> log4j.category.hivemind.examples.Adder=debug
May want a %c pattern, rather than %c{1}, so as to display all of "hivemind.examples.Adder".
>
> Now type in 'ant run' from the top-level directory and you
> should see the interceptor at work, printing out parameter
> values on entry, and the result upon exit:
>
> % ant run
> ...
> [java] 0 Adder [DEBUG] BEGIN add(11, 23)
> [java] 5 Adder [DEBUG] END add() [34]
> ...
>
> You can also get rough execution times for the methods by
> setting the pattern for the layout to include millisecond time values:
>
> log4j.appender.A1.layout.ConversionPattern=<%p %d{ISO8601} %c{1}> %m%n
>
> % ant run
> ...
> [java] <DEBUG 2003-09-16 09:46:02,034 Adder> BEGIN add(11, 23)
> [java] <DEBUG 2003-09-16 09:46:02,054 Adder> END add() [34]
> ...
>
> This shows that the Adder add method took about 20
> milliseconds to run. [Q: is this time at all accurate? Does
> it include any interceptor overhead, or is it mostly the
> method invocation?].
Java clock is very innacurate for short periods, less than around 60ms.
>
> In any case, just a suggestion.
>
> Next, I'm going to work on understanding extensions to
> services. Not sure I like the terms, "extension" or
> "extension-point". Configuring seems much less involved than
> extending, and HiveMind extensions seem to be all about
> configuring. Since I don't fully understand it, though, once
> I get through the doc and work through a few examples, I may
> change my view.
>
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
RE: [HiveMind] Suggestion for Bootstrap documentation addition / naming!
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Hold onto that; I'm getting close to checking in the refactored project, and we can apply the doc
change as a patch. Good points, very helpful.
<extension> and <extension-point> ... if you check the blog, you'll see I changed the names to be
more consistent with Eclipse, but that's seeming like less and less of a good idea. Refactoring
this now is painful, but will be worse later.
How about:
<extension-point> --> <configuration> and
<extension> --> <contribution>
<extend-service> --> <service-contribution> ?
With similar changes to the API (i.e. Registry.getExtensionPointElements() ->
getConfigurationElements()) and elsewhere (i.e, set-extension-point -> set-configuration).
Let's let this percolate for a few days, hear what people are thinking in terms of intuitive naming.
--
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:rael@zopyra.com]
> Sent: Tuesday, September 16, 2003 10:54 AM
> To: commons-dev@jakarta.apache.org
> Subject: [HiveMind] Suggestion for Bootstrap documentation addition
>
>
> I've just added my first interceptor. Neat stuff. I suggest
> we add a section to the example (Bootstrap) to show how to do
> this and how to configure the log4j properties (this was a
> bit confusing for me).
>
> Here is a sketch:
>
> Debugging the Example Using a Logging Interceptor
>
> Logging interceptors can be used to print out method
> invocation, including parameters passed and results returned.
> Adding a logging interceptor to a service is easy: add an
> interceptor clause to your HiveMind module, and set the log4j
> debug property on this interceptor to print out the
> information when the application is run.
>
> So, for our example, first add a logging interceptor to the HiveMind
> module:
>
> <?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.AdderImpl2"/>
>
> <interceptor service-id="hivemind.LoggingInterceptor"/>
> </service>
> </module>
>
> This interceptor will use the ID of the service within which
> it is operating, in this case 'hivemind.examples.Adder'.
>
> Next, set the debug level in the log4j.properties file by
> catenating 'log4j.category.' with the service id:
>
> log4j.category.hivemind.examples.Adder=debug
>
> The complete log4j file now looks something like this:
>
> log4j.rootCategory=WARN, A1
> log4j.appender.A1=org.apache.log4j.ConsoleAppender
> log4j.appender.A1.layout=org.apache.log4j.PatternLayout
> log4j.appender.A1.layout.ConversionPattern=%r %c{1} [%p] %m%n
> log4j.category.hivemind.examples.Adder=debug
May want a %c pattern, rather than %c{1}, so as to display all of "hivemind.examples.Adder".
>
> Now type in 'ant run' from the top-level directory and you
> should see the interceptor at work, printing out parameter
> values on entry, and the result upon exit:
>
> % ant run
> ...
> [java] 0 Adder [DEBUG] BEGIN add(11, 23)
> [java] 5 Adder [DEBUG] END add() [34]
> ...
>
> You can also get rough execution times for the methods by
> setting the pattern for the layout to include millisecond time values:
>
> log4j.appender.A1.layout.ConversionPattern=<%p %d{ISO8601} %c{1}> %m%n
>
> % ant run
> ...
> [java] <DEBUG 2003-09-16 09:46:02,034 Adder> BEGIN add(11, 23)
> [java] <DEBUG 2003-09-16 09:46:02,054 Adder> END add() [34]
> ...
>
> This shows that the Adder add method took about 20
> milliseconds to run. [Q: is this time at all accurate? Does
> it include any interceptor overhead, or is it mostly the
> method invocation?].
Java clock is very innacurate for short periods, less than around 60ms.
>
> In any case, just a suggestion.
>
> Next, I'm going to work on understanding extensions to
> services. Not sure I like the terms, "extension" or
> "extension-point". Configuring seems much less involved than
> extending, and HiveMind extensions seem to be all about
> configuring. Since I don't fully understand it, though, once
> I get through the doc and work through a few examples, I may
> change my view.
>
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org