I have heard more than one say that JMX is what Avalon is and much more.
As a reference they take JBoss, and say that if JBoss runs ok, what's the problem with JMX?
lack of contract. Avalon provides a contract. Design-by-contract. With JMX (like with early JBoss, its much better now and their interceptors are shaping up real well), you move your contract into xml files (that are modified through a web interface. With avalon, the contract is built using language-level features (to a degree).
I mean, it could be simple to simply make the lifecycle act as if there was Initializable if it finds an init() method, no?
yes. Dead simple.
class CustomLifecycleHelper extends LifecycleHelper { /** 50 lines of code here */ }
class CustomContainer extends DefaultContainer { /** change 3 lines here */ }
have a look at how plexus-new does it. Or pico.
Then they say that JMX is actually much more than that, because you can attach meta data.
In essence, what does Avalon lack to make JMX folks be compelled to use Avalon instead?
simplicity. Familiarity. Documentation. Big-money industry standard support.
What is missing for Avalon to be able to run JMX components OOTB?
some code. Of course, it is much easier to just run both JBoss and phoenix and use JNDI or altrmi or something like that....it never itched anyone enough I guess ;)
What does JMX lack that Avalon already gives?
rigidness. Use of language features like interfaces rather than dynamism. Proper seperation of concerns.
cheers!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
