Marc Boorshtein wrote:
Absolutely! I've only earned a couple hundred thousand dollars from my 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 still valid?).
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 toString().
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 go.
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 well).
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.
Jon Roberts www.mentata.com