On Fri, 16 Aug 2002, Steve Downey wrote: > > This really seems to pick the best APIs for the job. > > It's a good idea to use JNDI for configuration storing indeed, as it > > allows enterprise scale deployments, and seems generally better suited > > than JMX. > > > > Remy > > > > > To the extent that JNDI and JMX do the jobs they were designed for, it > makes perfect sense. JNDI is all about locating and retrieving data by > name. JMX is mostly a runtime mechanism for component management.
JMX has almost no support for storing the data ( the load/store are not even close to a real API like JNDI or prefs ). The real question for storage was JNDI or prefs - with prefs beeing a bit simpler. But I think as an API JNDI is far more powerfull and not that complex ( for simple tasks it is simple ). And it works in any VM ( including 1.1 ), is mature, etc. Both JMX and JNDI are about names and attributes. But JMX is very specialized to runtime. We could use JNDI for runtime API - it does have this flexibility - either as a wrapper on top of JMX or doing direct introspection. It is already used to store 'life' objects ( the java:env ), and it's not hard to extend it to support setAttribute() and operate like any DirContext on runtime objects. But it has no support for operations, and JMX has various unique features ( like SNMP, the HTTP adapter, etc ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
