Hi,
At 12:52 3/11/00 +0100, you wrote:
>> >Blocks seem to compare with JMX MBeans.
>>
>> sorta - MBeans are manageable classes while Blocks are components.
>
>Nope, MBeans are manageable components. That's how we use MBeans in
>jBoss anyway :-)
oh ;)
>> >Block dependencies are built into the blocks themselves. Not good.
>>
>> Sorta, relationships between blocks and services are hardwired (and why
>> shouldn't they be ?) but the actual implementations of services can vary.
>> So if you have a MailRepository hardwired as a service required then it can
>> be implemented by Database/File/mBox/other Repository and this is all
>> transparent to original block who just interacts via service interface.
>
>I understand what you say, but I still think that dependencies between
>server components should be handled externally. For example, if a
>service A needs a service of type Foo, and there are two services B and
>C that implement Foo, then one must be able to say that A depends on
>either B or C. External relationships allow you to do that, whereas the
>dependency mechanism in Avalon does not.
actually thats exactly what Avalon does. The only thing that is hardwired
is the service (ie Foo). When you configure it then your blocks can depend
on B, C or even D if someone creates a D as long as they conform to Foo ;)
>> >The engine seems to compare with a JMX MBeanServer, but not as clean.
>>
>> The engine is not as clean at the moment as it does a lot of management of
>> security features - I am actually refactoring these out at the moment. With
>> regard to the rest, a MBeanServer does not have the same functionality of
>> the kernel.
>>
>> The kernel is responsible for loading, configuring, rewiring, managing etc
>> Blocks. It builds a directed acyclic dependancy graph and can do all sorts
>> of things like hot-swap components and maintain specific relationships
>> between blocks etc. Think of it as equivelent o kernel of a microkernel
>> based OS.
>
>I repeat, this is very similar to a MBeanServer along with a couple of
>MBeans for some of the tasks you mention. This is precisely how we use
>it in jBoss, as a microkernel with components plugged into it. However,
>the kernel is only an aggregator, and not a source of actual
>functionality. The functionality is provided by MBeans. In this respect
>the JMX approach is cleaner IMO.
>
>For example, we have an MBean for loading, an MBean for configuration,
>an MBean for dependencies, etc.
Well there is already part of that there.
There shouldn't be IMHO a MBean/Block for dependency tracking because there
is really only one way you want it to run ;).
There is already configurable MBean/Component for configuration
(KernelConfigurator) and that will soon/currently is being experimented
with so that can grab config data from multiple data sources (ie
database/ldap server/filesystem).
As for a seperate component for loading, it is part of the way there. You
can already plug a new loader in via extending the kernel but as we only
need for one loader atm (namely from filesystem) then it is not developed
fully. Eventually it will be able to update from remote packages in a
secure manner as I need that functionality for a server application I am
writing ;). However in general I don't think pluggable loading is generally
needed. It is already a seperate component but there is no need to make it
generally pluggable aswell (that instance of flexability syndrome ;]).
>> It is hard to grok what Avalon is trying to do I guess. It doesn't aim to
>> provide checkbox features which is what you judged it on (and thus found
>> lacking) but is sort of a "best current practices" set of design patterns.
>
>Ah, but that is different, yes. I read the "Developer docs", which was
>much more interesting IMO. The patterns described are important, and we
>utilize quite a few of them already.
yep you have a similar design to Turbine (also at java.apache.org) which is
similar to ideas of Avalon minus Inversion of Control and less Seperation
of Concerns.
>> I guess if I was to indicate what exactly the Avalon framework is then it
>> would be the classes in the package org.apache.avalon (and none of the
>> subpackages) and all the associated design patterns with those classes.
>> Have a read of the webpages if you want to understand motivations for it ;)
>
>I think I have a better picture of what you want to accomplish. The goal
>is right, but as above the API's need to become more JMX'ish to be
>really cool :-)
;)
Will be more JMX-ish in the future. I believe Fede was part of the group
that wrote/reviewed/somethinged the JMX spec so I am sure he will JMx-ize
Avalon when the time is right. (Which IIRC correctly will be sometime
before end of year). All in good time ;)
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
