directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [naming] Next steps
Date Tue, 07 Dec 2004 04:44:46 GMT
Alex Karasulu wrote:
> Henri Yandell wrote:
>> Okay, I've woken up again Naming-wise :) Many thoughts, questions and
>> examples of how I don't understand JNDI/LDAP. This is all mostly to
>> Phil I assume.

>> * First off; what's the deal with the "java:" context. I've always
>> assumed that it's just for Java containers etc, and I can happily put
>> things in other contexts, but a remark from someone (Alex?) on the
>> list makes me think I may be clueless here.
> Yeah that's what I always thought: java:enc namespace is for J2EE 
> application configuration storage.

Yes, and resource references (jdbc connections, mail sessions, etc). 
The "java:comp/env" namespace is required by the J2EE spec, but the JNDI 
spec does not care about the content of names.

The "java:" means that a javaURLContextFactory will be used to create 
the context when an InitialContext instance is asked to lookup a name 
that starts with "java:".  This is the only scheme id supported by 
[naming] itself, but if you add (and configure, see 3.2.2 of the JNDI 
SPI spec for details) a fooURLContextFactory, you can handle names 
starting with the "foo:" scheme as well.  There is no need to use sheme 
ids at all.  I will modify the tests cases (and try to write some 
minimal docs) to make that clearer.
>> * My aim is to switch simple-jndi to using naming-core as its
>> underlying jndi engine. The only real feature I'll lose is that the
>> simple-jndi database is live, so I'll probably add some kind of
>> file-polling later on (Commons-IO needs that anyway if it's not
>> already there).

What do you mean "the database is live" - you mean it is backed by a 
persistent store that can be modified?  Seems to me that this use case 
would be better served by Eve (see Alex's earlier post).  [naming] is 
essentially an in-memory JNDI provider that can be bootstrapped from 
config files (or other persistent store).  I don't understand the use 
cases for file polling. Why not use the JNDI APIs?  What kind of thing 
do you have in mind here?
> That would be really nice.  If there were only a way to get notification 
> back from the file system of changes.  You can do that on windows but 
> not on other OSs it seems hence the lack of support in JDK.  But 
> notification of change over polling is an awesome thing to have.

What are the use cases?  Isn't it better to use the JNDI / LDAP APIs to 
listen for / trigger changes?
>> * Build instructions on the site. We need to get better instructions
>> there on how to check out of svn (all of directory needs this improved
>> I think, took me a long time to find the svn url). 

Agreed, though what we have here is not that bad:

I'd also suggest
>> that we switch to telling people to build core and factory
>> individually rather as a big multiproject build.

>> All the factory
>> dependency crap (javamail/jta etc) gets in the way of a nice easy core
>> build.

Yes, for maven.  The ant build works fine from /core with just commons 
collections and mx4j as dependencies.  The extra dependencies in the 
maven build must be coming from the POM inheritance.  I have not tried 
this, but overriding the combined dependencies in the parent in 
project.xml for core might work.  In any case, I agree that this needs 
to be cleaned up.  May be best to can the multiproject approach.

A bigger issue is the large number of dependencies in /factory and the 
question of whether or not the two packages are correctly divided.  Any 
thoughts on how this can be improved would be appreciated.

> +1 +1 = +2 for each point above.
> Alex

View raw message