geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guenther, Kurt - NASHCCON" <kurt.guenther.NASHC...@acs-inc.com>
Subject RE: Central piece: to JMX or not to JMX - Avalon
Date Thu, 07 Aug 2003 16:51:00 GMT

I've seen the reflection approach work out very well to the point where
generated code was no longer necessary to support EJB's.  When you see Sun's
CTS, you'll see where this would be valuable and it also lends itself to a
fluid development environment. 

I'm somewhat inclined to think reflection as a modus operandi for Geronimo's
backplane would be a good thing.

--Kurt


-----Original Message-----
From: Noel J. Bergman [mailto:noel@devtech.com]
Sent: Thursday, August 07, 2003 12:16 PM
To: Alex Blewitt; James Strachan
Cc: geronimo-dev@incubator.apache.org
Subject: RE: Central piece: to JMX or not to JMX - Avalon


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

Mime
View raw message