SSLFTPClient.auth() fails after re-deploys

Question

I'm using the edtFTPj/SSL client in a JBoss J2EE container. I have the client working fine for file transfers. However, when we do a hot re-deploy of our .ear archive the SSLFTPClient begins failing. Specifically, calling SSLFTPClient.auth(SSLFTPClient.AUTH_SSL) throws a NullPointerException.

If we do a restart of the JBoss container when we do a deploy everything is fine. So, this seems to be a ClassLoader issue of some kind, but I'm having trouble tracking it down.

Any suggestions on how I can force a reinitialization of the TLS keys programmatically?

I've included a portion of the stack trace here:

11:39:00,066 INFO [STDOUT] java.lang.NullPointerException
11:39:00,066 INFO [STDOUT] at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:143)
11:39:00,066 INFO [STDOUT] at org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:178)
11:39:00,066 INFO [STDOUT] at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:132)
11:39:00,066 INFO [STDOUT] at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
11:39:00,066 INFO [STDOUT] at java.security.Security.doGetImpl(Security.java:1123)
11:39:00,076 INFO [STDOUT] at java.security.Security.doGetImpl(Security.jav
a:1084)
11:39:00,076 INFO [STDOUT] at java.security.Security.getImpl Security.java:1045)
11:39:00,076 INFO [STDOUT] at java.security.MessageDigest.getInstance(MessageDigest.java:120)
11:39:00,076 INFO [STDOUT] at com.enterprisedt.net.puretls.TLSPRF.<init>(TLSPRF.java:132)
11:39:00,076 INFO [STDOUT] at com.enterprisedt.net.puretls.SSLPRF.getPRFInstance(SSLPRF.java:58)
11:39:00,076 INFO [STDOUT] at com.enterprisedt.net.puretls.SSLHandshake.computeMasterSecret(SSLHandshake.java:306)
11:39:00,076 INFO [STDOUT] at com.enterprisedt.net.puretls.SSLHandshakeClient.sendClientKeyExchange(SSLHandshakeClient.java:312)
11:39:00,076 INFO [STDOUT] at com.enterprisedt.net.puretls.SSLHandshakeClient.handshakeContinue(SSLHandshakeClient.java:138)
11:39:00,076 INFO [STDOUT] at com.enterprisedt.net.puretls.SSLHandshake.handshake(SSLHandshake.java:125)
11:39:00,076 INFO [STDOUT] at com.enterprisedt.net.puretls.SSLConn.handshake(SSLConn.java:143)
11:39:00,076 INFO [STDOUT] at com.enterprisedt.net.puretls.SSLSocket.handshake(SSLSocket.java:437)
11:39:00,076 INFO [STDOUT] at com.enterprisedt.net.ftp.ssl.B.H(Unknown Source)
11:39:00,076 INFO [STDOUT] at com.enterprisedt.net.ftp.ssl.SSLFTPClient.auth(Unknown Source)

Answer 1

Where are you keeping the edtFTPj/SSL jar file? Is it in the ear file? You could probably get around this by putting the jar in the main lib directory - worth a try to see if it works.

I'm using the edtFTPj/SSL client in a JBoss J2EE container. I have the client working fine for file transfers. However, when we do a hot re-deploy of our .ear archive the SSLFTPClient begins failing. Specifically, calling SSLFTPClient.auth(SSLFTPClient.AUTH_SSL) throws a NullPointerException.

If we do a restart of the JBoss container when we do a deploy everything is fine. So, this seems to be a ClassLoader issue of some kind, but I'm having trouble tracking it down.

)

Answer 2

Thanks, your suggestion does work. We're deploying with this solution for now.

This is not an ideal solution for us. We have many apps deployed to the same server cluster so we try to deploy our apps as self-contained .ear files and minimize the number of libraries we put out in the container's lib directory. Is there any other workaround that you're aware of?

Answer 3

No, it isn't ideal. Are you current customers or planning to become one? In those cases we can spend some time looking into this in more detail.

Thanks, your suggestion does work. We're deploying with this solution for now.

This is not an ideal solution for us. We have many apps deployed to the same server cluster so we try to deploy our apps as self-contained .ear files and minimize the number of libraries we put out in the container's lib directory. Is there any other workaround that you're aware of?

Answer 4

We are developing an FTPS client for deployment under WebSphere 5.1 and have noticed a similar exception when packaging edtftpj-ssl.jar in our ".war" (and ultimately the ".ear") file and attempting to do a re-deploy without restart. The exception we get is below. If we shutdown and restart everything is fine.

In the interim we have followed the suggestion of putting edtftpj-ssl.jar in the main library area, and we can do a re-deploy of our application without restart. As noted in the post of Aug. 11, this is not an ideal solution. Are there any plans to try to resolve this issue? (we are a current customer - let me know if you need more info).

Thanks,
Steve

java.lang.ClassCastException
at com.enterprisedt.net.puretls.TLSPRF.setKey(TLSPRF.java:256)
at com.enterprisedt.net.puretls.TLSPRF.P_hash(TLSPRF.java:231)
at com.enterprisedt.net.puretls.TLSPRF.PRF(TLSPRF.java:197)
at com.enterprisedt.net.puretls.SSLHandshake.computeMasterSecret(SSLHandshake.java:315)
at com.enterprisedt.net.puretls.SSLHandshakeClient.sendClientKeyExchange(SSLHandshakeClient.java:312)
at com.enterprisedt.net.puretls.SSLHandshakeClient.handshakeContinue(SSLHandshakeClient.java:138)
at com.enterprisedt.net.puretls.SSLHandshake.handshake(SSLHandshake.java:125)
at com.enterprisedt.net.puretls.SSLConn.handshake(SSLConn.java:143)
at com.enterprisedt.net.puretls.SSLSocket.handshake(SSLSocket.java:437)
at com.enterprisedt.net.ftp.ssl.B.H(Unknown Source)
at com.enterprisedt.net.ftp.ssl.SSLFTPClient.auth(Unknown Source)
at com.reyrey.ds.net.ftps.edt.FtpsClientImpl.setAuthType(FtpsClientImpl.java:287)
at com.reyrey.ds.net.ftps.edt.FtpsClientImpl.connect(FtpsClientImpl.java:207)
at com.reyrey.ds.ftps.DirList.getDir(DirList.java:626)
at com.reyrey.ds.ftps.DirList.listDirectory(DirList.java:512)
at com.reyrey.ds.ftps.DirList.processFtpsRequest(DirList.java:142)
at com.reyrey.ds.ftps.FtpsServerApp.processPostRequest(FtpsServerApp.java:379)
at com.reyrey.ds.webapp.WebServerApp.handlePostRequest(WebServerApp.java:1194)
at com.reyrey.ds.webapp.WebServerApp.exec(WebServerApp.java:151)
at com.reyrey.net.ServletAppLoader.execApp(ServletAppLoader.java:255)
at com.reyrey.net.ServletAppLoader.doPost(ServletAppLoader.java:121)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycleServlet.java:313)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:1019)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:592)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:204)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:125)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:286)
at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:182)
at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:615)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:439)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:912)

Answer 5

We never received a reply from michaelm so this had slipped off the horizon a little. We'll now spend some time looking into this - we'll get back to this forum. Thanks for the stack trace - that will help a lot. We'll email you or post here if we need any more details.

We are developing an FTPS client for deployment under WebSphere 5.1 and have noticed a similar exception when packaging edtftpj-ssl.jar in our ".war" (and ultimately the ".ear") file and attempting to do a re-deploy without restart. The exception we get is below. If we shutdown and restart everything is fine.

In the interim we have followed the suggestion of putting edtftpj-ssl.jar in the main library area, and we can do a re-deploy of our application without restart. As noted in the post of Aug. 11, this is not an ideal solution. Are there any plans to try to resolve this issue? (we are a current customer - let me know if you need more info).

Thanks,
Steve

Answer 6

Are there any plans to try to resolve this issue? (we are a current customer - let me know if you need more info).

We will have a possible solution for his problem ready within a few days. Would you be in a position to test it for us? If so, please contact support by e-mail and let us know where we can e-mail it to.

- Hans (EDT Support)

Answer 7

Yes, we are in a position to be able to test this. I will email my info to support@enterprisedt.com.

Thanks,
Steve