At 10:23 3/11/00 +0100, you wrote:
>Hi!
>
>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. In the
future dynamically generated MBean proxies will wrap around Blocks to
support blocks and provide managment but this is mediated by the kernel.
>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.
>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.
>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.
>The timeserver is similar to the JMX Time service.
timeserver is irrelevent to Avalon and could be removed.
>In general the remote administration workings is not as clean as in JMX
>Adaptors.
thats because it doesn't have remote administration yet ;) except for that
crappy telnet thing (and that is just for debugging). JMX will provide the
management facilities for Avalon but it is waiting to be integrated.
>The Avalon loader is similar to our org.jboss.Main.
right - it has less to do with Avalon and should be ignored
>A Store seems similar to our JMX Configuration MBean.
kinda, it represents an abstract store ie database/file/network/ldap
repositories - there is no actual implementations in Avalon besides trivial
file ones. The implementaions should occur in particular server application.
>The logging package is similar to our logging package. I expect both to
>change when the new JDK logging API is available.
right.
Ignore it - not part of Avalon as such.
>The testlet package is similar to jUnit.
yep - will soon be merged or succeeded by jUnit depending on the jUnit
authors wants. Ignore it - not part of Avalon as such.
>The rest of Avalon consists of various helper classes which may be
>useful or not.
Right - ignore them they are only a minor part of Avalon.
>All in all, I don't see anything really valuable that is not already
>provided either by our own APIs or by JMX. The stuff that mirrors JMX is
>not as clean and flexible as JMX.
right it doesn't have a list of checkbox features.
>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.
>To me, if
>Avalon is going to be useful it needs to
>1) Synchronize with JMX
will do soon - thou again that is a checkbox feature and not "part" of the
framework.
>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 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 ;)
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
