You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ole Arndt <ol...@sugarshark.com> on 2003/09/16 23:59:44 UTC
[HiveMind] Registry
Hello infant HiveMind community,
first a short self-introduction: I am a developer from Germany. For
my pet project, a mud like simulation, inhabited by (more or less) intelligent
agents, I was looking for a framework to use. I knew Avalon from my
job and had heard of pico- and swing container. When I discovered
HiveMind I was equally impressed by the underlying concepts, the
amount of documentation and the clean code.
Until now I haven't build anything with HiveMind but I have compiled
it, ran the tests and did some source code reading. I lurked on the
devel list (via gmane) for a few days to learn about the people and
the current status of the project. But now it's time to step forward
with a few questions/remarks. Here we go:
The HiveMind registry is currently static, right? Once constructed it
can't be changed. Due to the potentially very long run times of my
simulation I want to be able to add/remove modules/services on the fly
at any time. If get it right, this is currently only possible by
building an new registry. Correct?
What I want to have in the end is some kind of new service
notification mechanism like in the beancontext API, or with a Jini
lookup service. This does not need to be build into HiveMind, but is
probably only possible/easier with some support from the lower level.
Any plans in this direction or is this out-of-scope for HiveMind?
An easy improvement in this direction would be if the RegistryBuilder
took an old Registry to build upon as a parameter. This would probably
imply that the registry keeps its XML configuration.
Regarding the XML configuration: I agree that the current naming
really isn't very intuitive. I think the best proposal until now is
the one Harish made:
<service> --> <service-point>
<extend-service> --> <service>
<extension-point> --> <configuration-point>
<extension> --> <configuration>
Though, if some native English speaker found a more descriptive word for
`point', like `definition' but not as long, it would be even better :-)
Another issue: There isn't much visual difference between the
following two lines and that makes it hard to read:
<extension-point id="" />
<extension point-id="" />
What speaks against calling the id attribute `id' in both cases?
Ole
--
Ole Arndt http://www.sugarshark.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Registry
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Ole Arndt wrote:
>Hello infant HiveMind community,
>
>first a short self-introduction: I am a developer from Germany. For
>my pet project, a mud like simulation, inhabited by (more or less) intelligent
>agents, I was looking for a framework to use. I knew Avalon from my
>job and had heard of pico- and swing container. When I discovered
>HiveMind I was equally impressed by the underlying concepts, the
>amount of documentation and the clean code.
>
>Until now I haven't build anything with HiveMind but I have compiled
>it, ran the tests and did some source code reading. I lurked on the
>devel list (via gmane) for a few days to learn about the people and
>the current status of the project. But now it's time to step forward
>with a few questions/remarks. Here we go:
>
>The HiveMind registry is currently static, right? Once constructed it
>can't be changed.
>
This is correct.
>Due to the potentially very long run times of my
>simulation I want to be able to add/remove modules/services on the fly
>at any time. If get it right, this is currently only possible by
>building an new registry. Correct?
>
>What I want to have in the end is some kind of new service
>notification mechanism like in the beancontext API, or with a Jini
>lookup service. This does not need to be build into HiveMind, but is
>probably only possible/easier with some support from the lower level.
>
>Any plans in this direction or is this out-of-scope for HiveMind?
>
I think that will depend on the needs of the community, but Howard is
the best person to answer that.
>
>An easy improvement in this direction would be if the RegistryBuilder
>took an old Registry to build upon as a parameter. This would probably
>imply that the registry keeps its XML configuration.
>
>Regarding the XML configuration: I agree that the current naming
>really isn't very intuitive. I think the best proposal until now is
>the one Harish made:
>
><service> --> <service-point>
><extend-service> --> <service>
><extension-point> --> <configuration-point>
><extension> --> <configuration>
>
There you go..!!
>
>Though, if some native English speaker found a more descriptive word for
>`point', like `definition' but not as long, it would be even better :-)
>
>Another issue: There isn't much visual difference between the
>following two lines and that makes it hard to read:
>
><extension-point id="" />
><extension point-id="" />
>
>What speaks against calling the id attribute `id' in both cases?
>
I actually like this as it is more intuitive even if it is visually
confusing initially. You soon get used to it!
>
>Ole
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Registry
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Ole Arndt wrote:
>Hello infant HiveMind community,
>
>first a short self-introduction: I am a developer from Germany. For
>my pet project, a mud like simulation, inhabited by (more or less) intelligent
>agents, I was looking for a framework to use. I knew Avalon from my
>job and had heard of pico- and swing container. When I discovered
>HiveMind I was equally impressed by the underlying concepts, the
>amount of documentation and the clean code.
>
>Until now I haven't build anything with HiveMind but I have compiled
>it, ran the tests and did some source code reading. I lurked on the
>devel list (via gmane) for a few days to learn about the people and
>the current status of the project. But now it's time to step forward
>with a few questions/remarks. Here we go:
>
>The HiveMind registry is currently static, right? Once constructed it
>can't be changed.
>
This is correct.
>Due to the potentially very long run times of my
>simulation I want to be able to add/remove modules/services on the fly
>at any time. If get it right, this is currently only possible by
>building an new registry. Correct?
>
>What I want to have in the end is some kind of new service
>notification mechanism like in the beancontext API, or with a Jini
>lookup service. This does not need to be build into HiveMind, but is
>probably only possible/easier with some support from the lower level.
>
>Any plans in this direction or is this out-of-scope for HiveMind?
>
I think that will depend on the needs of the community, but Howard is
the best person to answer that.
>
>An easy improvement in this direction would be if the RegistryBuilder
>took an old Registry to build upon as a parameter. This would probably
>imply that the registry keeps its XML configuration.
>
>Regarding the XML configuration: I agree that the current naming
>really isn't very intuitive. I think the best proposal until now is
>the one Harish made:
>
><service> --> <service-point>
><extend-service> --> <service>
><extension-point> --> <configuration-point>
><extension> --> <configuration>
>
There you go..!!
>
>Though, if some native English speaker found a more descriptive word for
>`point', like `definition' but not as long, it would be even better :-)
>
>Another issue: There isn't much visual difference between the
>following two lines and that makes it hard to read:
>
><extension-point id="" />
><extension point-id="" />
>
>What speaks against calling the id attribute `id' in both cases?
>
I actually like this as it is more intuitive even if it is visually
confusing initially. You soon get used to it!
>
>Ole
>
>
RE: [HiveMind] Services and extensions ...
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Yes one module == one jar == one deployment descriptor.
To allow overriding of the service, you either don't provide an implementation, or follow the
guidelines on the web site about overridable services (adding
a level of indirection using substitution symbols).
--
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: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Thursday, September 18, 2003 8:40 AM
> To: Jakarta Commons Developers List
> Subject: Re: [HiveMind] Services and extensions ...
>
>
> When you say 'single location' is that in a single jar?
>
> Cause won't packaging the service together with the
> implementation prevent
> people from choosing a different implementation at deploy
> time? And to
> only allow them to add interceptors? Or have I
> mis-understood something?
>
> Johan
>
> On Thu, 18 Sep 2003 07:27:38 -0400, Howard M. Lewis Ship
> <hl...@comcast.net> wrote:
>
> > No, that separation is desirable in a small number of cases. Your
> > examples will be identical at
> > runtime.
> >
> > The typical usage is to define the service interface,
> implementation
> > and
> > interceptors in a single
> > location.
> > Here's a common scenario; you define a DAO (data access
> object) service
> > in module A with no impl.
> >
> > When your app runs against oracle, you deploy module A with
> module B,
> > which supplies Oracle
> > implementations.
> >
> > When your app runs against sql server, you deploy module A
> with module
> > C, which supplies sqlserver
> > implementations.
> >
> > In this way, you can use HiveMind as the uber-factory.
> >
> > --
> > 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: Johan Lindquist [mailto:johan@kawoo.co.uk]
> >> Sent: Thursday, September 18, 2003 6:44 AM
> >> To: Jakarta Commons Developers List
> >> Subject: [HiveMind] Services and extensions ...
> >>
> >>
> >> Is it desirable to have services defined in a single
> module and the
> >> extensions to those services defined in a separate module?
> >>
> >> Is there a difference between the following hivemodule xml?
> >>
> >>
> >> <?xml version="1.0"?>
> >> <module id="hivemind.examples" version="1.0.0">
> >> <service id="Adder" interface="hivemind.examples.Adder"
> >> model="singleton"/>
> >> <invoke-factory service-id="hivemind.BuilderFactory">
> >> <construct
> >> class="hivemind.examples.impl.AdderImpl">
> >> </construct>
> >> </invoke-factory>
> >> </service>
> >> </module>
> >>
> >> and
> >>
> >> <?xml version="1.0"?>
> >> <module id="hivemind.examples" version="1.0.0">
> >> <service id="Adder" interface="hivemind.examples.Adder"
> >> model="singleton"/>
> >> </module>
> >>
> >> <?xml version="1.0"?>
> >> <module id="hivemind.examples.impl" version="1.0.0">
> >> <extend-service service-id="hivemind.examples.Adder">
> >> <invoke-factory service-id="hivemind.BuilderFactory">
> >> <construct
> >> class="hivemind.examples.impl.AdderImpl">
> >> </construct>
> >> </invoke-factory>
> >> </extend-service>
> >> </module>
> >>
> >>
> ---------------------------------------------------------------------
> >> 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
> >
> >
>
>
>
> --
> you too?
>
> ---------------------------------------------------------------------
> 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] Services and extensions ...
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Yes one module == one jar == one deployment descriptor.
To allow overriding of the service, you either don't provide an implementation, or follow the
guidelines on the web site about overridable services (adding
a level of indirection using substitution symbols).
--
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: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Thursday, September 18, 2003 8:40 AM
> To: Jakarta Commons Developers List
> Subject: Re: [HiveMind] Services and extensions ...
>
>
> When you say 'single location' is that in a single jar?
>
> Cause won't packaging the service together with the
> implementation prevent
> people from choosing a different implementation at deploy
> time? And to
> only allow them to add interceptors? Or have I
> mis-understood something?
>
> Johan
>
> On Thu, 18 Sep 2003 07:27:38 -0400, Howard M. Lewis Ship
> <hl...@comcast.net> wrote:
>
> > No, that separation is desirable in a small number of cases. Your
> > examples will be identical at
> > runtime.
> >
> > The typical usage is to define the service interface,
> implementation
> > and
> > interceptors in a single
> > location.
> > Here's a common scenario; you define a DAO (data access
> object) service
> > in module A with no impl.
> >
> > When your app runs against oracle, you deploy module A with
> module B,
> > which supplies Oracle
> > implementations.
> >
> > When your app runs against sql server, you deploy module A
> with module
> > C, which supplies sqlserver
> > implementations.
> >
> > In this way, you can use HiveMind as the uber-factory.
> >
> > --
> > 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: Johan Lindquist [mailto:johan@kawoo.co.uk]
> >> Sent: Thursday, September 18, 2003 6:44 AM
> >> To: Jakarta Commons Developers List
> >> Subject: [HiveMind] Services and extensions ...
> >>
> >>
> >> Is it desirable to have services defined in a single
> module and the
> >> extensions to those services defined in a separate module?
> >>
> >> Is there a difference between the following hivemodule xml?
> >>
> >>
> >> <?xml version="1.0"?>
> >> <module id="hivemind.examples" version="1.0.0">
> >> <service id="Adder" interface="hivemind.examples.Adder"
> >> model="singleton"/>
> >> <invoke-factory service-id="hivemind.BuilderFactory">
> >> <construct
> >> class="hivemind.examples.impl.AdderImpl">
> >> </construct>
> >> </invoke-factory>
> >> </service>
> >> </module>
> >>
> >> and
> >>
> >> <?xml version="1.0"?>
> >> <module id="hivemind.examples" version="1.0.0">
> >> <service id="Adder" interface="hivemind.examples.Adder"
> >> model="singleton"/>
> >> </module>
> >>
> >> <?xml version="1.0"?>
> >> <module id="hivemind.examples.impl" version="1.0.0">
> >> <extend-service service-id="hivemind.examples.Adder">
> >> <invoke-factory service-id="hivemind.BuilderFactory">
> >> <construct
> >> class="hivemind.examples.impl.AdderImpl">
> >> </construct>
> >> </invoke-factory>
> >> </extend-service>
> >> </module>
> >>
> >>
> ---------------------------------------------------------------------
> >> 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
> >
> >
>
>
>
> --
> you too?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [HiveMind] Services and extensions ...
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
When you say 'single location' is that in a single jar?
Cause won't packaging the service together with the implementation prevent
people from choosing a different implementation at deploy time? And to
only allow them to add interceptors? Or have I mis-understood something?
Johan
On Thu, 18 Sep 2003 07:27:38 -0400, Howard M. Lewis Ship
<hl...@comcast.net> wrote:
> No, that separation is desirable in a small number of cases. Your
> examples will be identical at
> runtime.
>
> The typical usage is to define the service interface, implementation and
> interceptors in a single
> location.
> Here's a common scenario; you define a DAO (data access object) service
> in module A with no impl.
>
> When your app runs against oracle, you deploy module A with module B,
> which supplies Oracle
> implementations.
>
> When your app runs against sql server, you deploy module A with module
> C, which supplies sqlserver
> implementations.
>
> In this way, you can use HiveMind as the uber-factory.
>
> --
> 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: Johan Lindquist [mailto:johan@kawoo.co.uk]
>> Sent: Thursday, September 18, 2003 6:44 AM
>> To: Jakarta Commons Developers List
>> Subject: [HiveMind] Services and extensions ...
>>
>>
>> Is it desirable to have services defined in a single module and the
>> extensions to those services defined in a separate module?
>>
>> Is there a difference between the following hivemodule xml?
>>
>>
>> <?xml version="1.0"?>
>> <module id="hivemind.examples" version="1.0.0">
>> <service id="Adder" interface="hivemind.examples.Adder"
>> model="singleton"/>
>> <invoke-factory service-id="hivemind.BuilderFactory">
>> <construct
>> class="hivemind.examples.impl.AdderImpl">
>> </construct>
>> </invoke-factory>
>> </service>
>> </module>
>>
>> and
>>
>> <?xml version="1.0"?>
>> <module id="hivemind.examples" version="1.0.0">
>> <service id="Adder" interface="hivemind.examples.Adder"
>> model="singleton"/>
>> </module>
>>
>> <?xml version="1.0"?>
>> <module id="hivemind.examples.impl" version="1.0.0">
>> <extend-service service-id="hivemind.examples.Adder">
>> <invoke-factory service-id="hivemind.BuilderFactory">
>> <construct
>> class="hivemind.examples.impl.AdderImpl">
>> </construct>
>> </invoke-factory>
>> </extend-service>
>> </module>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
you too?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] Services and extensions ...
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
When you say 'single location' is that in a single jar?
Cause won't packaging the service together with the implementation prevent
people from choosing a different implementation at deploy time? And to
only allow them to add interceptors? Or have I mis-understood something?
Johan
On Thu, 18 Sep 2003 07:27:38 -0400, Howard M. Lewis Ship
<hl...@comcast.net> wrote:
> No, that separation is desirable in a small number of cases. Your
> examples will be identical at
> runtime.
>
> The typical usage is to define the service interface, implementation and
> interceptors in a single
> location.
> Here's a common scenario; you define a DAO (data access object) service
> in module A with no impl.
>
> When your app runs against oracle, you deploy module A with module B,
> which supplies Oracle
> implementations.
>
> When your app runs against sql server, you deploy module A with module
> C, which supplies sqlserver
> implementations.
>
> In this way, you can use HiveMind as the uber-factory.
>
> --
> 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: Johan Lindquist [mailto:johan@kawoo.co.uk]
>> Sent: Thursday, September 18, 2003 6:44 AM
>> To: Jakarta Commons Developers List
>> Subject: [HiveMind] Services and extensions ...
>>
>>
>> Is it desirable to have services defined in a single module and the
>> extensions to those services defined in a separate module?
>>
>> Is there a difference between the following hivemodule xml?
>>
>>
>> <?xml version="1.0"?>
>> <module id="hivemind.examples" version="1.0.0">
>> <service id="Adder" interface="hivemind.examples.Adder"
>> model="singleton"/>
>> <invoke-factory service-id="hivemind.BuilderFactory">
>> <construct
>> class="hivemind.examples.impl.AdderImpl">
>> </construct>
>> </invoke-factory>
>> </service>
>> </module>
>>
>> and
>>
>> <?xml version="1.0"?>
>> <module id="hivemind.examples" version="1.0.0">
>> <service id="Adder" interface="hivemind.examples.Adder"
>> model="singleton"/>
>> </module>
>>
>> <?xml version="1.0"?>
>> <module id="hivemind.examples.impl" version="1.0.0">
>> <extend-service service-id="hivemind.examples.Adder">
>> <invoke-factory service-id="hivemind.BuilderFactory">
>> <construct
>> class="hivemind.examples.impl.AdderImpl">
>> </construct>
>> </invoke-factory>
>> </extend-service>
>> </module>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
you too?
RE: [HiveMind] Services and extensions ...
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
No, that separation is desirable in a small number of cases. Your examples will be identical at
runtime.
The typical usage is to define the service interface, implementation and interceptors in a single
location.
Here's a common scenario; you define a DAO (data access object) service in module A with no impl.
When your app runs against oracle, you deploy module A with module B, which supplies Oracle
implementations.
When your app runs against sql server, you deploy module A with module C, which supplies sqlserver
implementations.
In this way, you can use HiveMind as the uber-factory.
--
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: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Thursday, September 18, 2003 6:44 AM
> To: Jakarta Commons Developers List
> Subject: [HiveMind] Services and extensions ...
>
>
> Is it desirable to have services defined in a single module and the
> extensions to those services defined in a separate module?
>
> Is there a difference between the following hivemodule xml?
>
>
> <?xml version="1.0"?>
> <module id="hivemind.examples" version="1.0.0">
> <service id="Adder" interface="hivemind.examples.Adder"
> model="singleton"/>
> <invoke-factory service-id="hivemind.BuilderFactory">
> <construct
> class="hivemind.examples.impl.AdderImpl">
> </construct>
> </invoke-factory>
> </service>
> </module>
>
> and
>
> <?xml version="1.0"?>
> <module id="hivemind.examples" version="1.0.0">
> <service id="Adder" interface="hivemind.examples.Adder"
> model="singleton"/>
> </module>
>
> <?xml version="1.0"?>
> <module id="hivemind.examples.impl" version="1.0.0">
> <extend-service service-id="hivemind.examples.Adder">
> <invoke-factory service-id="hivemind.BuilderFactory">
> <construct
> class="hivemind.examples.impl.AdderImpl">
> </construct>
> </invoke-factory>
> </extend-service>
> </module>
>
> ---------------------------------------------------------------------
> 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] Services and extensions ...
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
No, that separation is desirable in a small number of cases. Your examples will be identical at
runtime.
The typical usage is to define the service interface, implementation and interceptors in a single
location.
Here's a common scenario; you define a DAO (data access object) service in module A with no impl.
When your app runs against oracle, you deploy module A with module B, which supplies Oracle
implementations.
When your app runs against sql server, you deploy module A with module C, which supplies sqlserver
implementations.
In this way, you can use HiveMind as the uber-factory.
--
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: Johan Lindquist [mailto:johan@kawoo.co.uk]
> Sent: Thursday, September 18, 2003 6:44 AM
> To: Jakarta Commons Developers List
> Subject: [HiveMind] Services and extensions ...
>
>
> Is it desirable to have services defined in a single module and the
> extensions to those services defined in a separate module?
>
> Is there a difference between the following hivemodule xml?
>
>
> <?xml version="1.0"?>
> <module id="hivemind.examples" version="1.0.0">
> <service id="Adder" interface="hivemind.examples.Adder"
> model="singleton"/>
> <invoke-factory service-id="hivemind.BuilderFactory">
> <construct
> class="hivemind.examples.impl.AdderImpl">
> </construct>
> </invoke-factory>
> </service>
> </module>
>
> and
>
> <?xml version="1.0"?>
> <module id="hivemind.examples" version="1.0.0">
> <service id="Adder" interface="hivemind.examples.Adder"
> model="singleton"/>
> </module>
>
> <?xml version="1.0"?>
> <module id="hivemind.examples.impl" version="1.0.0">
> <extend-service service-id="hivemind.examples.Adder">
> <invoke-factory service-id="hivemind.BuilderFactory">
> <construct
> class="hivemind.examples.impl.AdderImpl">
> </construct>
> </invoke-factory>
> </extend-service>
> </module>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
[HiveMind] Services and extensions ...
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
Is it desirable to have services defined in a single module and the
extensions to those services defined in a separate module?
Is there a difference between the following hivemodule xml?
<?xml version="1.0"?>
<module id="hivemind.examples" version="1.0.0">
<service id="Adder" interface="hivemind.examples.Adder"
model="singleton"/>
<invoke-factory service-id="hivemind.BuilderFactory">
<construct
class="hivemind.examples.impl.AdderImpl">
</construct>
</invoke-factory>
</service>
</module>
and
<?xml version="1.0"?>
<module id="hivemind.examples" version="1.0.0">
<service id="Adder" interface="hivemind.examples.Adder"
model="singleton"/>
</module>
<?xml version="1.0"?>
<module id="hivemind.examples.impl" version="1.0.0">
<extend-service service-id="hivemind.examples.Adder">
<invoke-factory service-id="hivemind.BuilderFactory">
<construct
class="hivemind.examples.impl.AdderImpl">
</construct>
</invoke-factory>
</extend-service>
</module>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[HiveMind] Services and extensions ...
Posted by Johan Lindquist <jo...@kawoo.co.uk>.
Is it desirable to have services defined in a single module and the
extensions to those services defined in a separate module?
Is there a difference between the following hivemodule xml?
<?xml version="1.0"?>
<module id="hivemind.examples" version="1.0.0">
<service id="Adder" interface="hivemind.examples.Adder"
model="singleton"/>
<invoke-factory service-id="hivemind.BuilderFactory">
<construct
class="hivemind.examples.impl.AdderImpl">
</construct>
</invoke-factory>
</service>
</module>
and
<?xml version="1.0"?>
<module id="hivemind.examples" version="1.0.0">
<service id="Adder" interface="hivemind.examples.Adder"
model="singleton"/>
</module>
<?xml version="1.0"?>
<module id="hivemind.examples.impl" version="1.0.0">
<extend-service service-id="hivemind.examples.Adder">
<invoke-factory service-id="hivemind.BuilderFactory">
<construct
class="hivemind.examples.impl.AdderImpl">
</construct>
</invoke-factory>
</extend-service>
</module>
RE: [HiveMind] Registry
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Ole Arndt
> Sent: Tuesday, September 16, 2003 6:00 PM
> To: commons-dev@jakarta.apache.org
> Subject: [HiveMind] Registry
>
>
> Hello infant HiveMind community,
>
> first a short self-introduction: I am a developer from
> Germany. For my pet project, a mud like simulation, inhabited
> by (more or less) intelligent agents, I was looking for a
> framework to use. I knew Avalon from my job and had heard of
> pico- and swing container. When I discovered HiveMind I was
> equally impressed by the underlying concepts, the amount of
> documentation and the clean code.
Well, gosh thanks! Where do I send the check?
>
> Until now I haven't build anything with HiveMind but I have
> compiled it, ran the tests and did some source code reading.
> I lurked on the devel list (via gmane) for a few days to
> learn about the people and the current status of the project.
> But now it's time to step forward with a few
> questions/remarks. Here we go:
>
> The HiveMind registry is currently static, right? Once
> constructed it can't be changed. Due to the potentially very
> long run times of my simulation I want to be able to
> add/remove modules/services on the fly at any time. If get it
> right, this is currently only possible by building an new
> registry. Correct?
Dealing with those kinds of changes ... modules, services & etc. appearing,
disappearing and changing, is a bit of a nightmare. It adds and adds and adds
to the complexity of the HiveMind system, which is intended to complement
the applciation's classes as the static structure of the app, not its dynamic nature.
I believe Eclipse.org's Equinox project is attempting to solve thse problems, but I haven't the
bandwidth to see if they're accomplishing anything.
>
> What I want to have in the end is some kind of new service
> notification mechanism like in the beancontext API, or with a
> Jini lookup service. This does not need to be build into
> HiveMind, but is probably only possible/easier with some
> support from the lower level.
>
> Any plans in this direction or is this out-of-scope for HiveMind?
Probably out of scope; I would rather see your efforts to use HiveMind to build the infrastructure
to host your mutating, multiplying agents.
>
> An easy improvement in this direction would be if the
> RegistryBuilder took an old Registry to build upon as a
> parameter. This would probably imply that the registry keeps
> its XML configuration.
>
> Regarding the XML configuration: I agree that the current
> naming really isn't very intuitive. I think the best proposal
> until now is the one Harish made:
>
> <service> --> <service-point>
> <extend-service> --> <service>
> <extension-point> --> <configuration-point>
> <extension> --> <configuration>
>
> Though, if some native English speaker found a more
> descriptive word for `point', like `definition' but not as
> long, it would be even better :-)
>
> Another issue: There isn't much visual difference between the
> following two lines and that makes it hard to read:
>
> <extension-point id="" />
> <extension point-id="" />
Good point.
>
What speaks against calling the id attribute `id' in both cases?
I like id and point-id, but kind of favory <configuration-point> and <contribution> to keep the
things more visually distrinct.
--
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] Registry
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Ole Arndt
> Sent: Tuesday, September 16, 2003 6:00 PM
> To: commons-dev@jakarta.apache.org
> Subject: [HiveMind] Registry
>
>
> Hello infant HiveMind community,
>
> first a short self-introduction: I am a developer from
> Germany. For my pet project, a mud like simulation, inhabited
> by (more or less) intelligent agents, I was looking for a
> framework to use. I knew Avalon from my job and had heard of
> pico- and swing container. When I discovered HiveMind I was
> equally impressed by the underlying concepts, the amount of
> documentation and the clean code.
Well, gosh thanks! Where do I send the check?
>
> Until now I haven't build anything with HiveMind but I have
> compiled it, ran the tests and did some source code reading.
> I lurked on the devel list (via gmane) for a few days to
> learn about the people and the current status of the project.
> But now it's time to step forward with a few
> questions/remarks. Here we go:
>
> The HiveMind registry is currently static, right? Once
> constructed it can't be changed. Due to the potentially very
> long run times of my simulation I want to be able to
> add/remove modules/services on the fly at any time. If get it
> right, this is currently only possible by building an new
> registry. Correct?
Dealing with those kinds of changes ... modules, services & etc. appearing,
disappearing and changing, is a bit of a nightmare. It adds and adds and adds
to the complexity of the HiveMind system, which is intended to complement
the applciation's classes as the static structure of the app, not its dynamic nature.
I believe Eclipse.org's Equinox project is attempting to solve thse problems, but I haven't the
bandwidth to see if they're accomplishing anything.
>
> What I want to have in the end is some kind of new service
> notification mechanism like in the beancontext API, or with a
> Jini lookup service. This does not need to be build into
> HiveMind, but is probably only possible/easier with some
> support from the lower level.
>
> Any plans in this direction or is this out-of-scope for HiveMind?
Probably out of scope; I would rather see your efforts to use HiveMind to build the infrastructure
to host your mutating, multiplying agents.
>
> An easy improvement in this direction would be if the
> RegistryBuilder took an old Registry to build upon as a
> parameter. This would probably imply that the registry keeps
> its XML configuration.
>
> Regarding the XML configuration: I agree that the current
> naming really isn't very intuitive. I think the best proposal
> until now is the one Harish made:
>
> <service> --> <service-point>
> <extend-service> --> <service>
> <extension-point> --> <configuration-point>
> <extension> --> <configuration>
>
> Though, if some native English speaker found a more
> descriptive word for `point', like `definition' but not as
> long, it would be even better :-)
>
> Another issue: There isn't much visual difference between the
> following two lines and that makes it hard to read:
>
> <extension-point id="" />
> <extension point-id="" />
Good point.
>
What speaks against calling the id attribute `id' in both cases?
I like id and point-id, but kind of favory <configuration-point> and <contribution> to keep the
things more visually distrinct.
--
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