The Novell website doesn't give out the source code for JLDAP. I was thinking perhaps I could debug the problem myself and see if I can find the root cause. Would anyone be able to point me to the source code for JLDAP? And if I wanted to submit patches where I could do so?
Thanks in advance, Safdar On 9/9/05, Marc Boorshtein <[EMAIL PROTECTED]> wrote: > > Just a quick note on some of the things you've brought up: > > 1. Yes, the batting average on JLDAP (and JDBC-LDAP) has not been good. > I've tried my best to keep up, but have not been getting any support from > novell. > > 2. The dependencies issue was fixed. If you do not have the appropriate > libraries to support DSMLConnection or SPMLConnection then those classes are > skipped durring the compile. > > Marc > > On 9/9/05, Jon Roberts <[EMAIL PROTECTED]> wrote: > > > > Safdar Kureishy wrote: > > > Just so you know, I'm using different threads to run queries using > > cloned > > > connections from the same "master" connection... > > > > > > So when this problem occurs, all those threads seem to pile up one on > > top of > > > the other and remain blocked on the same call (as shown in the call > > stack). > > > > I have recently experienced failures resulting from blocked connections, > > too. I use the com.novell.ldap.connectionpool.PoolManager , which does > > something similar to your cloned connection approach. My assumption up > > to this point has been that it is related to ITS #3327 and/or ITS #3357, > > but I am currently rebuilding my development environment and can't yet > > easily test the patch submitted with #3357. I should be doing so in the > > coming weeks, and I'll share the results. > > > > I would like to take this opportunity to point out that the above-cited > > issues were reported over a year ago and have languished in ITS with > > OPEN status since then. I also wish to add that my own batting average > > is pretty low: I have submitted 3 JLDAP patches, each with unencouraging > > outcomes. The first (#3102) was inexplicably misapplied, leading to > > #3202 (fixed in CVS by June 2004 but only recently closed in ITS). The > > second (#3728) has been unregarded since its submission last May. > > Finally there's my most recent attempt to contribute (#3911), which is > > critical to enabling JLDAP to be compiled under Java v1.5 (it currently > > fails). This issue was successfully submitted Aug 1 and has now > > COMPLETELY DISAPPEARED FROM ITS! Thanks. > > > > It's not as if JLDAP has been inert; all sorts of arbitrary functions > > have been added by those with direct access to the code base in the > > meantime. I now see inconsistent naming/organizing (e.g. DsmlConnection > > vs. DSMLSearchResults vs. util.DSMLWriter). I get whole new dependencies > > > > every time I compile, which is why I now use my own Ant files to ignore > > dozens of classes when I build JLDAP. But hey, now I can use SPML just > > like LDAP (?), so who should care if the codebase might be broken, > > uncompilable, bloated, or ethnocentric, right? > > > > I have a great deal of respect for the OpenLDAP project and I have had > > many pleasant experiences with the Java LDAP APIs thus far to balance > > these criticisms. However, I do take issue with the recent JLDAP > > development direction. In short, I would prefer to see something that > > does the fundamentals effectively, cleanly, and flexibly vs. a sloppy > > repository for code that is all things to a few people. > > > > Jon Roberts > > www.mentata.com <http://www.mentata.com> > > > > ... forthwith donning my flame-retardant assflaps > > > >
