You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jonathan Duty <jd...@jonandkerry.com> on 2003/08/07 15:02:39 UTC
RE: Central piece: to JMX or not to JMX - Avalon
I think using Avalon (or Phoenix) is a great idea and something we
should look into. The Apache foundation has provided the world with
this great framework architecture, why not use it and practice what we
preach.
Just my thoughts,
Jonathan
Jonathan Duty
Software Developer - eWashtenaw
-----Original Message-----
From: Christian Trutz [mailto:chris@smilebase.org]
Sent: Thursday, August 07, 2003 7:48 AM
To: geronimo-dev@incubator.apache.org
Subject: Re: Central piece: to JMX or not to JMX
hi alex,
1+ for geronimo hasA JMX interface and not isA MBean
a proxy should be a good idea
should the Geronimo Kernel be something like Avalon??
(better something like Phoenix)
chris
RE: Central piece: to JMX or not to JMX - Avalon
Posted by "Noel J. Bergman" <no...@devtech.com>.
Alex,
> The FAQ from this point is:
> "Q: So is Geronimo going to be based on Avalon?
> A: To be certified Geronimo needs to fully support JMX and JNDI.
> ... etc ...
> I've already made a post to the effect of Geronimo isA JMX vs. Geronimo
> hasA JXM interface, and my preference is strongly for the latter.
> Has this decision already been taken to base it entirely on JMX ala
> JBoss? I really don't think that's the right way forward.
This community can make that decision as it puts together code. FWIW, I am
big on choice.
There is discussion about the next generation of Avalon having a model that
allows "container personalities", so a JMX personality would be a
possibility. Phoenix does have some support using MX4J.
I am cc'ing the Avalon folks to emphasize why this might be a good idea, but
it would be best of people interested in JMX support in an Avalon container
join dev@avalon.apache.org, and participate directly there.
--- Noel
RE: Central piece: to JMX or not to JMX - Avalon
Posted by "Noel J. Bergman" <no...@devtech.com>.
Alex,
> The FAQ from this point is:
> "Q: So is Geronimo going to be based on Avalon?
> A: To be certified Geronimo needs to fully support JMX and JNDI.
> ... etc ...
> I've already made a post to the effect of Geronimo isA JMX vs. Geronimo
> hasA JXM interface, and my preference is strongly for the latter.
> Has this decision already been taken to base it entirely on JMX ala
> JBoss? I really don't think that's the right way forward.
This community can make that decision as it puts together code. FWIW, I am
big on choice.
There is discussion about the next generation of Avalon having a model that
allows "container personalities", so a JMX personality would be a
possibility. Phoenix does have some support using MX4J.
I am cc'ing the Avalon folks to emphasize why this might be a good idea, but
it would be best of people interested in JMX support in an Avalon container
join dev@avalon.apache.org, and participate directly there.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Central piece: to JMX or not to JMX - Avalon
Posted by "Noel J. Bergman" <no...@devtech.com>.
Alex,
Present opinion:
> My opinion was that a kick-ass J2EE container would probably not be
> built on JMX, but instead provide an interface for JMX access on
> top (instead of underneath).
Too many posts stop with an opinion. You did the right thing.
Reasoning, benefit, offer to test:
> My reasoning behind the JMX issue is that it forces the development
> down one particular path, with a lot of JMX-intermediary-layer
> messages being bounced between different components. Removing that
> layer, and having direct messaging instead is bound to be faster,
> though this is a subjective observation rather than having detailed
> analysis to back that up. I'll do some tests and report back.
Statement of compatibility:
> Although having a JMX interface is needed, it doesn't need to be based
> on JMX, in much the same way that in order to interoperate with CORBA
> it doesn't need to be built on top of CORBA.
You are arguing that you feel that JMX provides flexibility at the expense
of performance, and are offering to test that belief. Your hypothetical
alternative would be to provide a higher performance component model, with
JMX where necessary/useful. Is that about right?
And James is able to come back and suggest particular places in existing
code that is being donated, so that you can see how it is doing things, and
see if it addresses your technical issue (performance) in another way:
> Once the code is online, take a look at the interceptor stack and see
> what you think.
There are multiple ways to solve a problem. Also, there are various
desiderata, such as performance, flexibility, stability (of both the code
and the community), ease of use, standardization, etc., to be balanced.
Whether your hypothesis is right or wrong, presenting a hypothesis for
discussion, measurable benefits, showing compatibility with necessary
standards, and offering to evaluate whether or not your hypothesis is
correct is a good way to go. You learn, others learn, the focus is on
improvement, and everyone wins. :-)
--- Noel
Re: Central piece: to JMX or not to JMX - Avalon
Posted by James Strachan <ja...@yahoo.co.uk>.
Alex
Once the code is online, take a look at the interceptor stack and see
what you think.
On Thursday, August 7, 2003, at 03:29 pm, Alex Blewitt wrote:
>>> A: To be certified Geronimo needs to fully support JMX and JNDI. So
>>> the current plan is to follow the direction of Tomcat 5, Jetty &
>>> JBoss and to use MBeans to register & wire the services together
>>> along with JNDI.
>>>
>>> Has this decision already been taken to base it entirely on JMX ala
>>> JBoss?
>>
>> So far yes. Right now like Tomcat 5, Jetty & JBoss we're using the
>> JMX component model for the foreseeable future along with our own
>> lifecycle mechanism closely tied with the J2EE deployment &
>> classloader mechanisms. Just because another services framework
>> exists it doesn't mean we have to use it. Though things may change in
>> the future.
>
>> Remember our aim is to build a kick ass J2EE container - not reuse
>> every bit of code we can find.
>>
>>> I really don't think that's the right way forward.
>>
>> Thats a convincing argument :) Why? I wonder why Tomcat 5, JBoss &
>> Jetty haven't jumped on Avalon either. Until we get going over here
>> why not start there first then come back here later when we're a
>> little more up to speed & things are documented & described a little
>> better & you've managed to convince Tomcat, Jetty or JBoss to ditch
>> JMX and use Avalon instead?
>
> I ought to be clearer in my posts ;-) I didn't necessarily advocate
> Avalon over Xxx; that was in response to a previous post.
>
> What I was saying, and had made a post to before, was that I can't see
> why we should be basing it on JMX [just because that's how Tomcat 5,
> Jetty, JBoss uses]. My opinion was that a kick-ass J2EE container
> would probably not be built on JMX, but instead provide an interface
> for JMX access on top (instead of underneath).
>
> My reasoning behind the JMX issue is that it forces the development
> down one particular path, with a lot of JMX-intermediary-layer
> messages being bounced between different components. Removing that
> layer, and having direct messaging instead is bound to be faster,
> though this is a subjective observation rather than having detailed
> analysis to back that up. I'll do some tests and report back.
>
> Although having a JMX interface is needed, it doesn't need to be based
> on JMX, in much the same way that in order to interoperate with CORBA
> it doesn't need to be built on top of CORBA.
>
> These were the thoughts behind the original post, and the follow on
> from the Avalon post led me to the FAQ answer with the 'We are using
> JMX' answer, hence this query.
>
> Alex.
>
>
James
-------
http://radio.weblogs.com/0112098/
Re: Central piece: to JMX or not to JMX - Avalon
Posted by Alex Blewitt <Al...@bandlem.com>.
>> A: To be certified Geronimo needs to fully support JMX and JNDI. So
>> the current plan is to follow the direction of Tomcat 5, Jetty &
>> JBoss and to use MBeans to register & wire the services together
>> along with JNDI.
>>
>> Has this decision already been taken to base it entirely on JMX ala
>> JBoss?
>
> So far yes. Right now like Tomcat 5, Jetty & JBoss we're using the JMX
> component model for the foreseeable future along with our own
> lifecycle mechanism closely tied with the J2EE deployment &
> classloader mechanisms. Just because another services framework exists
> it doesn't mean we have to use it. Though things may change in the
> future.
> Remember our aim is to build a kick ass J2EE container - not reuse
> every bit of code we can find.
>
>> I really don't think that's the right way forward.
>
> Thats a convincing argument :) Why? I wonder why Tomcat 5, JBoss &
> Jetty haven't jumped on Avalon either. Until we get going over here
> why not start there first then come back here later when we're a
> little more up to speed & things are documented & described a little
> better & you've managed to convince Tomcat, Jetty or JBoss to ditch
> JMX and use Avalon instead?
I ought to be clearer in my posts ;-) I didn't necessarily advocate
Avalon over Xxx; that was in response to a previous post.
What I was saying, and had made a post to before, was that I can't see
why we should be basing it on JMX [just because that's how Tomcat 5,
Jetty, JBoss uses]. My opinion was that a kick-ass J2EE container would
probably not be built on JMX, but instead provide an interface for JMX
access on top (instead of underneath).
My reasoning behind the JMX issue is that it forces the development
down one particular path, with a lot of JMX-intermediary-layer messages
being bounced between different components. Removing that layer, and
having direct messaging instead is bound to be faster, though this is a
subjective observation rather than having detailed analysis to back
that up. I'll do some tests and report back.
Although having a JMX interface is needed, it doesn't need to be based
on JMX, in much the same way that in order to interoperate with CORBA
it doesn't need to be built on top of CORBA.
These were the thoughts behind the original post, and the follow on
from the Avalon post led me to the FAQ answer with the 'We are using
JMX' answer, hence this query.
Alex.
Re: Central piece: to JMX or not to JMX - Avalon
Posted by James Strachan <ja...@yahoo.co.uk>.
On Thursday, August 7, 2003, at 02:57 pm, Alex Blewitt wrote:
>>> I think using Avalon (or Phoenix) is a great idea and something we
>>> should look into.
>>
>> The initial contributors did look into this (see below).
>
> The FAQ from this point is:
>
> "Q: So is Geronimo going to be based on Avalon?
>
> A: To be certified Geronimo needs to fully support JMX and JNDI. So
> the current plan is to follow the direction of Tomcat 5, Jetty & JBoss
> and to use MBeans to register & wire the services together along with
> JNDI.
>
> There are a lot of different 'services frameworks' such as JMX,
> Avalon, PicoContainer?, Spread, Java Beans etc. The only one we
> absolutely must support is JMX - so we'll focus on that first. However
> there is no reason why Geronimo cannot have other kinds of containers
> dropped in as services (Avalon, PicoContainer? or whatever). From
> Geronmio's perspective its just a bunch of MBeans. "
>
> I think that although Geronimo needs to /support/ JMX and JNDI, it
> doesn't need to be /built/ in terms of JMX and JNDI. So it could (for
> example) be built on top of Avalon, and have JMX interfaces for the
> things that need it.
>
> I've already made a post to the effect of Geronimo isA JMX vs.
> Geronimo hasA JXM interface, and my preference is strongly for the
> latter.
>
> Has this decision already been taken to base it entirely on JMX ala
> JBoss?
So far yes. Right now like Tomcat 5, Jetty & JBoss we're using the JMX
component model for the foreseeable future along with our own lifecycle
mechanism closely tied with the J2EE deployment & classloader
mechanisms. Just because another services framework exists it doesn't
mean we have to use it. Though things may change in the future.
Please give us some time to find our feet & grow - at least let us get
CVS setup with the initial codebase before commenting on the code that
you've not seen yet :).
There are lots of things on our plate - but lets not dive in deciding
which frameworks should be reused before you've studied what we're
actually doing and so can make a considered judgment on the right thing
to do for Geronimo, the J2EE container (rather than Avalon).
Remember our aim is to build a kick ass J2EE container - not reuse
every bit of code we can find.
> I really don't think that's the right way forward.
Thats a convincing argument :) Why? I wonder why Tomcat 5, JBoss &
Jetty haven't jumped on Avalon either. Until we get going over here why
not start there first then come back here later when we're a little
more up to speed & things are documented & described a little better &
you've managed to convince Tomcat, Jetty or JBoss to ditch JMX and use
Avalon instead?
James
-------
http://radio.weblogs.com/0112098/
Re: Central piece: to JMX or not to JMX - Avalon
Posted by Alex Blewitt <Al...@ioshq.com>.
>> I think using Avalon (or Phoenix) is a great idea and something we
>> should look into.
>
> The initial contributors did look into this (see below).
The FAQ from this point is:
"Q: So is Geronimo going to be based on Avalon?
A: To be certified Geronimo needs to fully support JMX and JNDI. So the
current plan is to follow the direction of Tomcat 5, Jetty & JBoss and
to use MBeans to register & wire the services together along with JNDI.
There are a lot of different 'services frameworks' such as JMX, Avalon,
PicoContainer?, Spread, Java Beans etc. The only one we absolutely must
support is JMX - so we'll focus on that first. However there is no
reason why Geronimo cannot have other kinds of containers dropped in as
services (Avalon, PicoContainer? or whatever). From Geronmio's
perspective its just a bunch of MBeans. "
I think that although Geronimo needs to /support/ JMX and JNDI, it
doesn't need to be /built/ in terms of JMX and JNDI. So it could (for
example) be built on top of Avalon, and have JMX interfaces for the
things that need it.
I've already made a post to the effect of Geronimo isA JMX vs. Geronimo
hasA JXM interface, and my preference is strongly for the latter.
Has this decision already been taken to base it entirely on JMX ala
JBoss? I really don't think that's the right way forward.
Alex.
Re: Central piece: to JMX or not to JMX - Avalon
Posted by James Strachan <ja...@yahoo.co.uk>.
On Thursday, August 7, 2003, at 02:02 pm, Jonathan Duty wrote:
> I think using Avalon (or Phoenix) is a great idea and something we
> should look into.
The initial contributors did look into this (see below).
> The Apache foundation has provided the world with
> this great framework architecture, why not use it and practice what we
> preach.
This has already come up several times already and we're not even 2
days old yet so I've posted a FAQ.
http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/FAQ
James
-------
http://radio.weblogs.com/0112098/