You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/07/21 08:48:42 UTC
JMX in Avalon
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?
One thing that I've see users start to dislike about Avalon is the
dependency on the Avalon interfaces. JMX instead looks like totally
dynamic, with no binding.
As I see it, is there a reason why we need to *impose* our interfaces?
I mean, it could be simple to simply make the lifecycle act as if there
was Initializable if it finds an init() method, no?
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?
What is missing for Avalon to be able to run JMX components OOTB?
What does JMX lack that Avalon already gives?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: JMX in Avalon
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
Nicola,
>>
>> If we head down the JMX before Java-interfaces road, we may as well
>> throw away Avalon. It is better that we stick to A-F and automagic
>> wrapping of JMX capability by one of our containers.
>
>
> Yes, this is an interesting solution, i thought about that too.
> Basically make our containers be able to run JMX and expose as JMX but
> not necessarily *be* JMX-based.
It is what Phoenix does. I'm going to take a guess that Merlin does too.
- Paul
--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: JMX in Avalon
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote, On 21/07/2003 10.27:
> Nicola,
>
> If we head down the JMX before Java-interfaces road, we may as well
> throw away Avalon. It is better that we stick to A-F and automagic
> wrapping of JMX capability by one of our containers.
Yes, this is an interesting solution, i thought about that too.
Basically make our containers be able to run JMX and expose as JMX but
not necessarily *be* JMX-based.
> - Paul
>
>> 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? [.....]
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: JMX in Avalon
Posted by Paul Hammant <Pa...@ThoughtWorks.net>.
Nicola,
If we head down the JMX before Java-interfaces road, we may as well
throw away Avalon. It is better that we stick to A-F and automagic
wrapping of JMX capability by one of our containers.
- Paul
> 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? [.....]
--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: JMX in Avalon
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
> 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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org