directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: Embedding Eve Was: To release or not to release?
Date Thu, 25 Nov 2004 19:35:47 GMT
Phil Steitz wrote:

> From the various recent posts, it seems we have two basic use cases 
> here and possibly two solutions for one of them -- maybe not a bad 
> thing, but something to think about.
>
> 1) Centralized access to configuration information and object 
> references for physically distributed systems
>
> 2) Bootstrapping and providing local, in-memory access to 
> configuration / object references based on information in local flat 
> files.
>
> In Java, we want to use the JNDI client API in both cases. 1) is a 
> classic application for Directory Services and certainly part of the 
> motivation for Eve.  For 2) either embedded Eve or [naming] will work. 
> I am interested in understanding the pros and cons of these two 
> approaches.  We may want to merge them in some way (i.e., modify 
> [naming] to just front embedded Eve). Does this make sense?

I'm not yet familiar enough with Eve to say, but it would have to be 
able to perform all the functionality of naming without requiring an 
onerous amount of additional configuration or dependencies to make 
sense. I'm not sure this would be the case. What probably makes more 
sense to have Eve use naming if that makes any sense, and keep naming as 
a small library for the purposes of (2).

However, being able to embed Eve offers richer functionality to an 
application that might be useful even for doing (2).

>
> FWIW, I would not want to see Tomcat or Geronimo completely abandon 2) 
> -- i.e., become wholly dependent on centralized "administrative 
> repositories". There are some practical advantages to having basic 
> configuration information available locally.
>
I agree - one reason to use JNDI for the client is to be able to switch 
between or combine two depending on the deployment environment.

Cheers,
Brett


Mime
View raw message