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:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 12:16 PM To: Alex Blewitt; James Strachan Cc: [EMAIL PROTECTED] 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
