This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have a fairly complex webapp that leveraged LDAP/S for communication with backend LDAP server. With the profiler disabled (ie, no modification of the catalina.bat file), everything works as expected. In order to use the cacerts file, I copied the one I have configured that trusts the internal CA in question to the: C:\Program Files\Netbeans 4.1Beta\platform5\modules\profiler-ea-vm\jre\lib\security directory. Once I enable the profiler (I have tested it's functionality and it works as expected), the call to the JNDI libs result in the following stacktrace: javax.naming.CommunicationException: simple bind failed: tekncdc03.testmov.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: No trusted certificate found] at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:198) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2640) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:290) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243) at javax.naming.InitialContext.init(InitialContext.java:219) at javax.naming.InitialContext.<init>(InitialContext.java:195) at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:80) at com.tekelec.corpdir.ad.ADHelper.getInitialContext(ADHelper.java:325) at com.tekelec.corpdir.ad.ADHelper.logonServiceAccount(ADHelper.java:639) at com.tekelec.oid.OIDHelper.getADHelper(OIDHelper.java:2883) ... I have verified which cacerts file tomcat is looking for with the help of NT File Monitor. It is locating the cacerts file correctly. For whatever reason, it acts as though it doesn't understand the contents or some other problem. Many thanks! -Sean
Huh, sounds weird. Misha, do you have any idea what could cause this?
Sorry about a delay with reply - I've just returned from vacation. It's not immediately clear what could have caused this problem, but I suspect that it may be related to our customized VM/JDK version. To try to isolate the problem, I suggest you do the following: 1. Select the vanilla JDK 1.4.2_xx release that works for your application. 2. From our custom JDK installation (located in ...\modules\profiler-ea-vm), copy the following files into your vanilla JDK installation: jre\bin\client\jvm.dll jre\bin\server\jvm.dll (it won't be bad to save the original .dlls, just in case) This will convert your vanilla JDK into "JFluid JDK" by replacing just the JVM core libraries, but not touching anything else. Let us know if the resulting JDK works for you. If it doesn't, we will see what else can be done. Regards, Misha
To the user who reported this problem: please let us know if the suggested measures helped. Otherwise, I will close this issue in one or two days. Note that if this is a JDK incompatibility problem, it will be solved automatically in a few months, when the tool will finally run on a standard JDK 5/6. Thanks and Best Regards, Misha
Closing this issue, assuming that it was a JDK/JVM incompatibility problem indeed.
Please do not close the issue. It is not resolved. I have been far too busy with other responsibilities at work to perform the recommended test. I will get to it sometime this week. If it's fixed, where is the patch? Regards, -sean
Sorry, if my theory above works, there will be no patch for this issue. There is always a chance that some particular JDK 1.4.2_xx version will not work with some application (we are aware of a couple of other cases), but we can't distribute our customized JVM with 7 or 8 different JDKs (1.4.2_01 .. 1.4.2_08). However, in the other cases I mentioned, placing our JVM library into an appropriate JDK version worked without problems. I would appreciate you testing this issue soon - we plan to release Milestone 6 release of the Profiler in a few days, and if this problem is actually something different than above, it would be good if we could fix it in this release.
I will make a pointed effort to test this hypotheis Monday. I will update this bug with the results. Thanks for the understanding! _Sean
Postponed to M7
Ok, the next release of the Profiler (M6) is out, and I really would like to figure out if this issue is still a problem. Please check this as you've promised, otherwise I will close it again in a couple of days. Regards, Misha
I'll see what I can do. Been in .NET training the last week. Should be able to test tomorrow or Tuesday.
Since there is still no confirmation of this issue, I am closing it.
Verification of old issues.
Closing old issues.