It would be a single service, but could easily be adapted for distributed systems. For example, each Geronimo app server is likely to have a server VM running server services, which could include the JNDI server. Then, each other node has a JNDI server which synchronizes its state with the others.

With a backend DB, it's very likely that the DB could be used to provide the synchronization. Files may be more problematic, unless they are on a network device.

So, doesn't necessarily need to be a single point of failure although it would be a single service.

Alex.

On Friday, Aug 8, 2003, at 20:31 Europe/London, Gareth Bryan wrote:

I like this idea:- but wouldn't it introduce a single point of failure?

(I guess the same problem will hold for any config node in a cluster)

On Fri, 8 Aug 2003 19:28:26 +0100, "Philip Dodds"
<[EMAIL PROTECTED]> said:
I certainly agree. The idea of holding all configuration information in
a
repository such as LDAP would certainly be useful within clustered and
grid
style environments.


Philip

-----Original Message-----
From: Alex Blewitt [mailto:[EMAIL PROTECTED]
Sent: Friday, August 08, 2003 6:55 PM
To: [EMAIL PROTECTED]
Subject: [JNDI] [Config] Thought

Why can't/shouldn't all configuration be stored in JNDI, presumably as
subdirectory (sorry, subcontext) specific to geronimo?
(java:comp/env/genronimo, or other such domain).

JNDI supports pretty much everything you need -- contexts (one per
server/node/app/ejb/servlet/whatever) and an unlimited amount of
configuration entries (poolsize, max thread, min thread).

And if the JNDI is going to be backed by Technology X, then that
provides a way for users to administer the data directly. But a app
configurator can just be based on reading/writing JNDI values.

JNDI also not only supports tree-like structures, but also references
to other parts of the tree as well which would be ideal (for instance)
to represent relationships like 'App Y is in node Z'

And lastly, XML extraction of a JNDI source would be a doddle, or even
be backed by the JNDI-XML server (though IMHO a JNDI-DB server will be
more scalable for read-write data synchronised across multiple nodes
for clustering).

Can anyone think of a good reason why JNDI cannot/should not be used as
/the/ place to store config information? That way, the server will only
need one start-up parameter -- the JNDI server to connect to.


Alex.

PS Isn't this what Windows 2000 uses for its registry, and what Windows
XP uses to mount its Active Directory? Certainly, Mac OS X is moving
more towards a directory-managed approach (be it backed by LDAP or
whatever) -- so why don't we do the same for Geronimo?





--
  Gareth Bryan
  [EMAIL PROTECTED]

--
http://www.fastmail.fm - mmm... Fastmail...



Reply via email to