Marc Boorshtein wrote:
>Absolutely! I've only earned a couple hundred thousand dollars
>operational experiences with JLDAP. Unfortunately, besides Marc those
>many other voices don't speak much about the Java LDAP code anymore,
>neither here nor at Novell's mailing JLDAP list. You yourself have said
>more about my work in your concise responses over the years than any of
>them. Hence, I've become accustomed to living in feedback deficit.
I do have to say this is a consistent problem with JLDAP. I like it
far more then JNDI but it just doesn't seem to have much adoption. At
one point Sun was talking about adding an LDAP api like JLDAP to Java,
but when I brought up JLDAP or even the Mozilla stuff it went no
where. That list has been pretty quite for the last few months, and
with the turmoil over at sun around OpenDS I wouldn't hold my breath.
Back in the earliest days of the Netscape Java LDAP libraries, it seemed
Sun viewed the approach as competitive rather than complimentary (ditto
Linux). I'd like to assume times have changed. I wrote the OpenDS
project lead a long message on the subject of Java LDAP earlier this
year and was ignored. I'm naive to any turmoil, and I don't hold my
breath for anything anymore.
I personally think the best solution to revitalizing JLDAP is for those
of us that care to clear the outstanding ITS reports and then refactor
what's there as a way to assume a sense of ownership within the OpenLDAP
project. I'm not suggesting taking anything from Novell or making
radical changes; more like a systematic review that gives new blood some
skin in the code base. I mean JLDAP has classes that have been
deprecated for five years now.
Better yet would be to follow the OpenLDAP development model and start a
new branch for a new version (e.g. 2.3 to 2.4). That would be huge
though, so the breath holding heuristic again applies.
>And as for Marc's plan to change the toString() method to
return "", I
>would have preferred the approach Michael implied where null means an
>undefined instance and "" is the RootDSE (an honest-to-god node in the
>DIT). I'll have some time, so I'd be happy to clean up the whole class
>over the next few weeks if nobody objects (and if my privileges are
Hmm, while I appreciate the argument about 'new DN("") == RootDSE'
from a conceptual standpoint, from a pure Java standpoint I don't
think its proper for an initialized object to return null from
I do agree, but what I said originally is that the class permits the
construction of an uninitialized DN for whatever reason. My thinking is
always that if null is a possible state, it should be a possible outcome.
I can't think of any examples that do this in Java and I
can say that returning null from toString() has caused me no end of
heartburn over at MyVirtualDirectory.
Now that's an argument I can understand, yet I'm not familiar with
MyVirtualDirectory. Why does it have the potential to call toString() on
uninitialized DN instances? Is it a matter of checking for null in lots
of places? Is the problem inherent to something external like use with
J2EE? I'm not debating the point, I'm just curious.
I would much rather have
RootDSE be a constant on either LDAPConnection or DN then have null
returned from toString().
That's a thought. Or as I said if it's uninitialized then it's the
RootDSE, period. That would be a documentation fix.
As null is not a String I don't think its
an accurate String representation of the DN class or an instance of
it. So for both the pure Java related reasoning above and the wording
of the RFC (as well as the feedback from the other java based ldap
projects) I feel returning "" from toString is really the only way to
I'm satisfied. Like I said, I have yet use the call anyway.
Jon, by 'Clean Up' what do you mean?
I'd have to look deeper to answer, but deprecating/removing the
redundant methods for a start. I was really just thinking this class
would be an ideal place to start refactoring because it's utility,
peripheral, and concise. PoolManager would be another one, because it
has bugs to boot. That's where I was headed just before my personal life
got sent through the meat grinder.
To be honest my issues are less
with the DN class its self and more with its inconsistent use in JLDAP
(ie the Entry class takes a String for its DN and returns a String as
As I said, I use the DN class to parse distinguished names where I need
to, but Strings are the currency for most of my program logic. On the
other hand, I would definitely see the value of alternate methods to
take and return DN values wherever possible. It wouldn't be that difficult.
I could think of a few new features (ie a bit more control
over the RDNs).
Right. I was thinking something could be done here too. Like I said, I'd
have to take a longer look than I did.
I don't know what your current time constraints are. As I've said, mine
aren't pretty. I remember before you didn't have much to give.
Regardless, I think the two of us at least should start a more concerted
effort in this vein at whatever pace we can afford. Anything is better
than watching this nifty library wither from neglect.
Feel free to reach me off-list.