I just tested it, and the fix seems to work well. At first I thought that your null check would actually cause a problem, in case the exception is something besides a connection(or socket) closed, and the provider chose to not to set the message on the exception. But, I think the fact that the retry is wrapped in yet another try catch block means that life will probably go on. I've been doing all sorts of fun weird things to my LDAP server to try to get other types of exceptions thrown, and it behaves as I would expect with your fix.
With defect 20518 -- It does seem innocent, though if the primary LDAP server is down for an extended period of time, you would constantly be trying it first, then the alternate. But, I'm guessing the performance hit is not huge and the fix seems correct beyond that. (IE, to assume the primary is forever gone is a bad idea and it is better to take the potential performance hit). You closed the bug regarding the userSubtree not working I see. I'm not sure but that there are still issues there, and I'm still investigating. I can get it to work if I add the [Public] object as a trustee to any subcontext that I want searched, but this is by no means a standard thing to do since it opens up your user containers to potential security exploits. Most of the exploits involve social engineering; with public access to the names of the users in the container, you can impersonate a user whose name you see and call up and ask a help desk technician to change their password for you. What I'm not sure about is if there is some other acceptable way to grant browse rights to some other object and then have Tomcat go in as that object. If so, then that would need to be documented if it is not already. If that is not possible, then the userSubtree feature is fairly useless since most directory administrators would not take the security risk to make it work. Also, there are other bugs with this feature like the fact that the first level is not searched for users, ONLY the sublevels are. I emailed marek about the CLIENT-CERT problem, still no response. I'm going to look into it and see what the gist of Mario's objections were, and if the patch is good. I know nothing about the iPlanet issue (except for what is in the bug report), so that will be great if you have a fix... Thanks Tim for working on these issues. Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.com >>> [EMAIL PROTECTED] 8/5/03 11:42:43 AM >>> I got eager and saw you bug update yesterday and applied a patch to 4.1 last night. Here's a link to the PATCH email: http://marc.theaimsgroup.com/?l=tomcat-dev&m=106004487327965&w=2 The commit also does a null pointer check on the getMessage() to fix a related bug and also avoids doing the toString(). As for bug 20518 - did this seem right? It seemed like an innocent fix. (But they are the ones that seem to cause the most trouble) IIRC, the only two bugs left I know of is: 1) The CLIENT-CERT one which I wish not to do but rather leave to someone to Extend JNDIRealm. (But if someone else wants to commit it - I won't care) 2) Enhancement request for IPlanet since in a non-user binding the SHA1 check isn't compatible with the way tomcat generates a hash. I have a patch on my own from another project that might fix this. (If I can find the code) AFAIK - All other JNDIRealm bugs are fixed or enhancements. If you can test from 4.1 and give me the OK - I can port the patch to 5. (I know I committed in the wrong order :( , but did it on the hope that the patch had a better chance of being tested) -Tim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
