Oh good,
on top of a rabid license "10 years in jail" freak, we can now see an
educated technologist... good, then welcome, and keep that way...
|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.
what do you call the kernel?
are your proxies remotely put?
|>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.
I will have to go with Rickard here. The "management dependencies" is
something independent of the blocks but dependent on the context of a
particular deployment/environment/application. To have the dependencies in
the beans and "hardwired" (I don't understand the scope of "hardwire"
though). In any case, the dependencies are VERY runtime oriented and the
external management of them (JMX) is the way to go. Take a look at
"inprise"'s stuff.
|>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
yes management of security is management of a service and the nature of the
service/server should not be exposed in the MBeanServer (or your equivalent
level)... if it is you haven't purified it, That's all rickard is saying.
|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
oooh fancy, a directed acyclic dependancy graph...
|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.
Ok you load the different modules in the server ,pretty much the role of the
MBean Server but the dependency is again "supra-module" and context
dependent... the "fancy graph" doesn't really belong there. The server
start-stops, loads/unloads etc etc it is blind. Period, move on, the rest
is higher management of services/applications/clients...
|>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.
mmmmmmmmmm I have serious questions then.. honestly a Management framework
that only works for "file configuration " ( I assume you feed it information
from somewhere, very static) and doesn't offer me STANDARD interfaces to
talk to it (look at Mad Andy's work on RMI/JMX, and the http:8082 port of
jboss) is pretty much useless from a "dynamic module loading" standpoint.
There is another dimension... how am I to hook up ANY management tool to
that. Ok it's a trick question since I am part of group 77 and that is what
we are looking into. Http management is a biggy, already there, thrown in
for free by JMX
|>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.
|
yep there is going to be a lot of rewiring when that comes out (finally)
|>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.
ok, we are in our 3rd iteration of "best current practices" and there is
whole lot to be said. It boils down to: I believe you have 2 steps to do
with avalon
1- percolation: put your stuff under fire, most of it will burn (this class
not important, that doesn't belong here, that's security, that's app
dependent etc etc) right now it is a lot of things to a lot of people from
what I gather, if feels 1st generation moving on to 2nd...
2- go for *standard* (gaddamit), if the industry is going to go and plug
tools in a framework you better be compliant, otherwise, only Apache tools
are going to be talking to apache tools, and that is seriously not a
situation you want to be in. Specifically not in j2ee, this is not NT.
|>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.
Daniel, this is more than a checkbox... learn from the standard, they have
already "percolated", save yourselves that "deep" refactoring and get
outside help in form of a spec.
|>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 don't know the codebase enough to make a "yep, no fat now" kinda
statement.
I will believe it when a totally different code base from one of your peers
replaces it.
|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 ;)
yes imho it's a bit all over the place. It is a repository of "folksy
knowledge" right now, with good coders at the head. My guess is that it
needs time.
Take a good look at JMX as a "MBeanServer", and "remote access to
invocation" thing. It is not much more and clean.
regards
marc
|
|
|Cheers,
|
|Pete
|
|*------------------------------------------------------*
|| "Nearly all men can stand adversity, but if you want |
|| to test a man's character, give him power." |
|| -Abraham Lincoln |
|*------------------------------------------------------*
|
|
