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.
Blocks seem to compare with JMX MBeans.
Block dependencies are built into the blocks themselves. Not good.
Relationships between blocks need to be defined externally in order to
be really flexible. The JMX relationship service handles this better I
think.
The engine seems to compare with a JMX MBeanServer, but not as clean.
The timeserver is similar to the JMX Time service.
In general the remote administration workings is not as clean as in JMX
Adaptors.
The Avalon loader is similar to our org.jboss.Main.
A Store seems similar to our JMX Configuration MBean.
The logging package is similar to our logging package. I expect both to
change when the new JDK logging API is available.
The testlet package is similar to jUnit.
The rest of Avalon consists of various helper classes which may be
useful or not.
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.
So, that's my first impression. Feel free to disagree :-) To me, if
Avalon is going to be useful it needs to
1) Synchronize with JMX
2) Get a whole lot slimmer. Many classes seem to be in the "might be
useful" category. A healthy refactorization is recommended.
regards,
Rickard, jBoss dev.
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
