This one time, at band camp, Alex Blewitt said:
AB>On Monday, Aug 11, 2003, at 07:07 Europe/London, Weston M. Price wrote:
AB>
AB>> I agree with Gareth,I am not quite sure of why JMX would not be used,
AB>> or would
AB>> be replaced at some other time.
AB>>
AB>> On Monday 11 August 2003 09:28 am, Gareth Bryan wrote:
AB>>>> On Mon, 11 Aug 2003 04:40:40 -0400, "Noel J. Bergman"
AB>>>> <[EMAIL PROTECTED]>
AB>>>> said:
AB>>>>
AB>>>> Jason Dillon wrote:
AB>>>>> we will eventually want to replace the JMX bus with a more
AB>>>>> robust component system.
AB>>>>
AB>>>> The sense I am getting from the list is that there is a decent sized
AB>>>> base
AB>>>> of
AB>>>> people who agree with you, and who see JMX as an interface TO a
AB>>>> component
AB>>>> system, not AS the component system.
AB>>>
AB>>> I get that sense aswell, although personally, I haven't spoken up
AB>>> about
AB>>> it before now because I wanted to take a look at the seed code. My
AB>>> initial opinion is that I'd like to see some hard evidence for the
AB>>> drawbacks for using JMX, putting it another way: I'm a +1 for JMX at
AB>>> the
AB>>> moment.
AB>
AB>A number of people are saying 'Lets go with the JMX bus until another
AB>choice is made later'. The question is, why was the JMX bus chosen in
AB>the first place? Because other implementations (e.g. JBoss) used that
AB>approach.
AB>
AB>The problem is that JMX was designed as an interface to allow remote
AB>programs to manage/start/stop services on a remote machine using an
AB>arbitrary client. JBoss does as much in its administration console,
AB>which is nothing more than a glorified send-a-JMX-message system.
AB>
AB>The other reason why JMX is used as the initial bus is that J2EE must
AB>have a JMX interface. That said, it doesn't need to be implemented
AB>using JMX (in much the same way that we don't need to build a J2EE
AB>server using CORBA although CORBA requests may/must be supported).
AB>
AB>Unfortunately, the isA/hasA debate is something that can run and run
AB>and run, and since the initial code seed has gone with JMX then it
AB>seems very difficult to nudge that another way. But a more generic
AB>container framework (the likes of
AB>Avalon/Merlin/Hivemind/Eclipse-Plugin-Style) that /has/ a JMX interface
AB>would be a 'cleaner' approach from an OO perspective.
A very interesting point here, Alex.
...
AB>Lastly, if the focus is on 'The kernel is JMX' then that may
AB>unnecessarily affect design decisions: 'Hey, lets use MBeans defined in
AB>XML on a single flat file'. We could follow JBoss' example and do this;
AB>or we could be more innovative, using a configuration registry backed
AB>with JNDI/LDAP, whilst still providing a Management interface over JMX.
I was actually thinking about another discussion discussing the storage
of configuration metadata in some type of respository. The first thing
that comes to my mind is a solution accessible via JNDI and backed by
anything that is JNDI accessible. LDAP would be my first choice as well,
but because not every environment can deal with LDAP, the JNDI interface
allows anything to be implemented. This need could certainly be met by the
LDAPd project which is currently trying to become an Incubator project.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL
PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
