Hi!
Peter Donald wrote:
> >Peter Donald wrote:
> >> While [Avalon] will eventually also become a toolbox of lego-like blocks
> that you
> >> can join together to build a server this is not it's main aim I believe.
> >
> >Alright, looked at the Avalon API, and here are my impressions.
>
> kewl ;)
>
> >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 :-)
> >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.
> >Relationships between blocks need to be defined externally in order to
> >be really flexible. The JMX relationship service handles this better I
> >think.
>
> Not sure what you mean here.
See JMX specs for reference.
> >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.
> >So, that's my first impression. Feel free to disagree :-)
>
> 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.
In my mind the API of Avalon is not *that* valuable in light of JMX.
IMHO the best way to proceed for Avalon is to refactor the existing
functionality into straight MBeans, and skip the kernel stuff which is
provided by MBeanServer's (or make it an MBeanServer if you want to).
Then they would be much more valuable to us.
> >2) Get a whole lot slimmer. Many classes seem to be in the "might be
> >useful" category. A healthy refactorization is recommended.
>
> Actually you would be surprised then that almost all of them are used in
> one project or another. It has already been slimmed down ;)
>
> I guess think of it in the same way as you treat pattern based design. It
> doesn't "do" anything, doesn't give ready made "solutions" for particular
> applications (thou it may in future) however what it does do is give you a
> way to think about problem space. If you are a "hacker" at heart and
> believe everything should be in assembly then it obviously isn't for you
> but if you do a lot of design then it is very good framework to think in.
> (Even if you don't end up using the actual classes).
I see. Well, then I would recommend jBoss developers to read the Avalon
"Developer docs", and apply that to what is done in our server. That
would make sense. As for the rest, see above.
> 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 :-)
regards,
Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
