geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: [JNDI] [Config] Thought
Date Fri, 08 Aug 2003 20:52:27 GMT
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"
> <philip.dodds@unity-financials.com> 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:Alex.Blewitt@ioshq.com]
>> Sent: Friday, August 08, 2003 6:55 PM
>> To: geronimo-dev@incubator.apache.org
>> 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
>   garethbryan@fastmail.fm
>
> -- 
> http://www.fastmail.fm - mmm... Fastmail...


Mime
View raw message