Re: Trouble with jdbc drivers in TC 7
On Thursday 07 April 2011 22:17:22 Christopher Schultz wrote: Could you be missing a shared library from your java.library.path? Sometimes, missing shared libs can cause CNFEs. The folder where the .dlls are located is on the windows %path%. Is that part of the java.library.path? If not, where is the best place to put them? JRE\lib\ext\x86? Are you running Tomcat as a service? If so, the Windows %PATH% might not be applying. Can you try inspecting your Tomcat 5.5 configuration to see where those .dll files might be, or if the java.library.path is being specified somewhere? The OP should be able to inspect the actually applied value with JMX (e.g. (j)visualvm). Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Trouble with jdbc drivers in TC 7
System: Windows Server 2008 R2 Standard (64-bit) JRE: 1.6.0_24 x64 TC: 7.0.11, installed in c:\Program Files\..., so it detected an x64 installation DB: Sybase ASA 9.0.2.3951, x64 version DB server and TC are both installed on this same machine. I'm trying to port my app from tc 5.5.something late, to 7.0, and can't get my app to find the driver class. It all works fine under TC 5.5. All my database pooling is done in the application, so I thought putting the jodbc.jar in the WEB-INF/lib of the app would work with no need to edit my configuration files, but I'm still getting the class not found error below. I have also tried moving jodbc.jar to %catalina_home%/lib, but that didn't help either. RtData64 is the 64-bit ODBC DSN, which test ok in ODBC admin. I have opened jodbc.jar to be sure it has ianywhere.ml.jdbcodbc.IDriver inside it. Am I missing some configuration requirements? I can't find anything in the online docs that would indicate I need to do anything, since I'm not having TC handle the connection pooling. Dave Thu Apr 07 12:09:56 EDT 2011: Exception in class: com.wra.websira.WraAdmin, Msg: 'Initialization', Exception: java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver Thu Apr 07 12:09:56 EDT 2011: Exception in class: com.wra.websira.WraJdbc, Msg: 'Creating database: RtData64', Exception: java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at com.wra.websira.WraDatabase.open(WraDatabase.java:64) at com.wra.websira.WraJdbc.init(WraJdbc.java:46) at com.wra.websira.WraAdmin.init(WraAdmin.java:257) at com.wra.websira.WraAdmin.validateUser(WraAdmin.java:594) at com.wra.websira.WraAdmin.validateUser(WraAdmin.java:451) at eddsrv.LoginBean.verifyUser(LoginBean.java:41) at org.apache.jsp.Login_jsp._jspService(Login_jsp.java:144) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:391) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:498) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:394) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:284) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:322) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1714) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Trouble with jdbc drivers in TC 7
From: David kerber [mailto:dcker...@verizon.net] Subject: Trouble with jdbc drivers in TC 7 All my database pooling is done in the application, so I thought putting the jodbc.jar in the WEB-INF/lib of the app would work with no need to edit my configuration files I think that should work. Check carefully that you don't have multiple copies of the driver jar lying around. Extra copies beyond the one in the proper location can get you CNFE. Is there a possible permissions issue preventing the Tomcat account from accessing the jar? (Less likely on Windows, but it can happen.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with jdbc drivers in TC 7
On 4/7/2011 2:16 PM, Caldarale, Charles R wrote: From: David kerber [mailto:dcker...@verizon.net] Subject: Trouble with jdbc drivers in TC 7 All my database pooling is done in the application, so I thought putting the jodbc.jar in the WEB-INF/lib of the app would work with no need to edit my configuration files I think that should work. Check carefully that you don't have multiple copies of the driver jar lying around. Extra copies beyond the one in the proper location can get you CNFE. Is there a possible permissions issue preventing the Tomcat account from accessing the jar? (Less likely on Windows, but it can happen.) No luck with either of those. I checked for extra copies of jodbc.jar, and gave full control permissions to everybody on the webapp folder and subfolders. Was something changed in 7 from previous versions wrt database connections? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Trouble with jdbc drivers in TC 7
From: David kerber [mailto:dcker...@verizon.net] Subject: Re: Trouble with jdbc drivers in TC 7 Was something changed in 7 from previous versions wrt database connections? Even if it had been changed, it shouldn't matter in your case, since you're handling your own connections. This looks more like a classloader problem; is your webapp creating its own classloader? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with jdbc drivers in TC 7
On 4/7/2011 3:28 PM, Caldarale, Charles R wrote: From: David kerber [mailto:dcker...@verizon.net] Subject: Re: Trouble with jdbc drivers in TC 7 Was something changed in 7 from previous versions wrt database connections? Even if it had been changed, it shouldn't matter in your case, since you're handling your own connections. This looks more like a classloader problem; is your webapp creating its own classloader? No, I'm not doing anything with classloaders. At least not intentionally :-/ - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with jdbc drivers in TC 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 4/7/2011 2:08 PM, David kerber wrote: System: Windows Server 2008 R2 Standard (64-bit) JRE: 1.6.0_24 x64 TC: 7.0.11, installed in c:\Program Files\..., so it detected an x64 installation DB: Sybase ASA 9.0.2.3951, x64 version [snip] I have also tried moving jodbc.jar to %catalina_home%/lib, but that didn't help either. Is this a pure Java driver? JDBC-ODBC drivers (which looks like yours might be) often have a native component. Could you be missing a shared library from your java.library.path? Sometimes, missing shared libs can cause CNFEs. Another possibility is that you are using a 64-bit JVM and a 32-bit native driver, which may cause some problems. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2eEhwACgkQ9CaO5/Lv0PC7CACgu2Lg4I1Xqu9WP6xyMfBKkSLs VGwAn2gOctnIR9WfjYkGww9CEkG1Y6e+ =a9+l -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with jdbc drivers in TC 7
On 4/7/2011 3:35 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 4/7/2011 2:08 PM, David kerber wrote: System: Windows Server 2008 R2 Standard (64-bit) JRE: 1.6.0_24 x64 TC: 7.0.11, installed in c:\Program Files\..., so it detected an x64 installation DB: Sybase ASA 9.0.2.3951, x64 version [snip] I have also tried moving jodbc.jar to %catalina_home%/lib, but that didn't help either. Is this a pure Java driver? JDBC-ODBC drivers (which looks like yours It is a jdbc-odbc bridge driver, and has windows dlls. might be) often have a native component. Could you be missing a shared library from your java.library.path? Sometimes, missing shared libs can cause CNFEs. The folder where the .dlls are located is on the windows %path%. Is that part of the java.library.path? If not, where is the best place to put them? JRE\lib\ext\x86? Another possibility is that you are using a 64-bit JVM and a 32-bit native driver, which may cause some problems. I checked that long ago; they are both 64-bit. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2eEhwACgkQ9CaO5/Lv0PC7CACgu2Lg4I1Xqu9WP6xyMfBKkSLs VGwAn2gOctnIR9WfjYkGww9CEkG1Y6e+ =a9+l -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with jdbc drivers in TC 7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David, On 4/7/2011 4:09 PM, David kerber wrote: On 4/7/2011 3:35 PM, Christopher Schultz wrote: David, On 4/7/2011 2:08 PM, David kerber wrote: System: Windows Server 2008 R2 Standard (64-bit) JRE: 1.6.0_24 x64 TC: 7.0.11, installed in c:\Program Files\..., so it detected an x64 installation DB: Sybase ASA 9.0.2.3951, x64 version [snip] I have also tried moving jodbc.jar to %catalina_home%/lib, but that didn't help either. Is this a pure Java driver? JDBC-ODBC drivers (which looks like yours It is a jdbc-odbc bridge driver, and has windows dlls. Could you be missing a shared library from your java.library.path? Sometimes, missing shared libs can cause CNFEs. The folder where the .dlls are located is on the windows %path%. Is that part of the java.library.path? If not, where is the best place to put them? JRE\lib\ext\x86? Are you running Tomcat as a service? If so, the Windows %PATH% might not be applying. Can you try inspecting your Tomcat 5.5 configuration to see where those .dll files might be, or if the java.library.path is being specified somewhere? Check the configuration options shown by the service configuration program (tomcat5w.exe?) -- there might be a library path set in there somewhere. Another possibility is that you are using a 64-bit JVM and a 32-bit native driver, which may cause some problems. I checked that long ago; they are both 64-bit. Glad to see that's not the problem. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2eG9IACgkQ9CaO5/Lv0PDS8QCgoU6uqRGSZsfS5/uElITCMM0/ iGgAn26FDxPeRIdiygOuncRnAXtvNVTG =NakR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with jdbc drivers in TC 7
The config has changed from Resource ... param to Resource driverClassName= that could be your culprit On 4/7/2011 12:08 PM, David kerber wrote: System: Windows Server 2008 R2 Standard (64-bit) JRE: 1.6.0_24 x64 TC: 7.0.11, installed in c:\Program Files\..., so it detected an x64 installation DB: Sybase ASA 9.0.2.3951, x64 version DB server and TC are both installed on this same machine. I'm trying to port my app from tc 5.5.something late, to 7.0, and can't get my app to find the driver class. It all works fine under TC 5.5. All my database pooling is done in the application, so I thought putting the jodbc.jar in the WEB-INF/lib of the app would work with no need to edit my configuration files, but I'm still getting the class not found error below. I have also tried moving jodbc.jar to %catalina_home%/lib, but that didn't help either. RtData64 is the 64-bit ODBC DSN, which test ok in ODBC admin. I have opened jodbc.jar to be sure it has ianywhere.ml.jdbcodbc.IDriver inside it. Am I missing some configuration requirements? I can't find anything in the online docs that would indicate I need to do anything, since I'm not having TC handle the connection pooling. Dave Thu Apr 07 12:09:56 EDT 2011: Exception in class: com.wra.websira.WraAdmin, Msg: 'Initialization', Exception: java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver Thu Apr 07 12:09:56 EDT 2011: Exception in class: com.wra.websira.WraJdbc, Msg: 'Creating database: RtData64', Exception: java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at com.wra.websira.WraDatabase.open(WraDatabase.java:64) at com.wra.websira.WraJdbc.init(WraJdbc.java:46) at com.wra.websira.WraAdmin.init(WraAdmin.java:257) at com.wra.websira.WraAdmin.validateUser(WraAdmin.java:594) at com.wra.websira.WraAdmin.validateUser(WraAdmin.java:451) at eddsrv.LoginBean.verifyUser(LoginBean.java:41) at org.apache.jsp.Login_jsp._jspService(Login_jsp.java:144) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:391) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:498) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:394) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:284) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:322) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1714) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1209 / Virus Database: 1500/3557 - Release Date: 04/07/11 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with jdbc drivers in TC 7
On 4/7/2011 5:01 PM, Filip Hanik - Dev Lists wrote: The config has changed from Resource ... param to Resource driverClassName= I don't use any of those, because TC isn't managing the pool; the app handles its own pool. The file layout that works in 5.5 doesn't seem to work in 7.0, unless there's some very subtle difference I'm not seeing. that could be your culprit On 4/7/2011 12:08 PM, David kerber wrote: System: Windows Server 2008 R2 Standard (64-bit) JRE: 1.6.0_24 x64 TC: 7.0.11, installed in c:\Program Files\..., so it detected an x64 installation DB: Sybase ASA 9.0.2.3951, x64 version DB server and TC are both installed on this same machine. I'm trying to port my app from tc 5.5.something late, to 7.0, and can't get my app to find the driver class. It all works fine under TC 5.5. All my database pooling is done in the application, so I thought putting the jodbc.jar in the WEB-INF/lib of the app would work with no need to edit my configuration files, but I'm still getting the class not found error below. I have also tried moving jodbc.jar to %catalina_home%/lib, but that didn't help either. RtData64 is the 64-bit ODBC DSN, which test ok in ODBC admin. I have opened jodbc.jar to be sure it has ianywhere.ml.jdbcodbc.IDriver inside it. Am I missing some configuration requirements? I can't find anything in the online docs that would indicate I need to do anything, since I'm not having TC handle the connection pooling. Dave Thu Apr 07 12:09:56 EDT 2011: Exception in class: com.wra.websira.WraAdmin, Msg: 'Initialization', Exception: java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver Thu Apr 07 12:09:56 EDT 2011: Exception in class: com.wra.websira.WraJdbc, Msg: 'Creating database: RtData64', Exception: java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at com.wra.websira.WraDatabase.open(WraDatabase.java:64) at com.wra.websira.WraJdbc.init(WraJdbc.java:46) at com.wra.websira.WraAdmin.init(WraAdmin.java:257) at com.wra.websira.WraAdmin.validateUser(WraAdmin.java:594) at com.wra.websira.WraAdmin.validateUser(WraAdmin.java:451) at eddsrv.LoginBean.verifyUser(LoginBean.java:41) at org.apache.jsp.Login_jsp._jspService(Login_jsp.java:144) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:391) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:498) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:394) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:284) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:322) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1714) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with jdbc drivers in TC 7 - fixed
To close this loop, I got it fixed. The issue was a (apparently very slightly) corrupt jodbc.jar file. I say very slightly because I could open it with windows explorer's .zip handling functionality and everything looked fine, but tomcat choked on it when trying to open it with java.util.zip. Tomcat was throwing exceptions at startup, but they were quite a bit further up in the log from the one I posted here, and I didn't see them for the longest time. The CNFE was due to the .jar containing the class not being opened because of the unzipping error. Reinstalling the software update got me a good .jar file, and now it all works. Thanks for your patience! D On 4/7/2011 5:05 PM, David kerber wrote: On 4/7/2011 5:01 PM, Filip Hanik - Dev Lists wrote: The config has changed from Resource ... param to Resource driverClassName= I don't use any of those, because TC isn't managing the pool; the app handles its own pool. The file layout that works in 5.5 doesn't seem to work in 7.0, unless there's some very subtle difference I'm not seeing. that could be your culprit On 4/7/2011 12:08 PM, David kerber wrote: System: Windows Server 2008 R2 Standard (64-bit) JRE: 1.6.0_24 x64 TC: 7.0.11, installed in c:\Program Files\..., so it detected an x64 installation DB: Sybase ASA 9.0.2.3951, x64 version DB server and TC are both installed on this same machine. I'm trying to port my app from tc 5.5.something late, to 7.0, and can't get my app to find the driver class. It all works fine under TC 5.5. All my database pooling is done in the application, so I thought putting the jodbc.jar in the WEB-INF/lib of the app would work with no need to edit my configuration files, but I'm still getting the class not found error below. I have also tried moving jodbc.jar to %catalina_home%/lib, but that didn't help either. RtData64 is the 64-bit ODBC DSN, which test ok in ODBC admin. I have opened jodbc.jar to be sure it has ianywhere.ml.jdbcodbc.IDriver inside it. Am I missing some configuration requirements? I can't find anything in the online docs that would indicate I need to do anything, since I'm not having TC handle the connection pooling. Dave Thu Apr 07 12:09:56 EDT 2011: Exception in class: com.wra.websira.WraAdmin, Msg: 'Initialization', Exception: java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver Thu Apr 07 12:09:56 EDT 2011: Exception in class: com.wra.websira.WraJdbc, Msg: 'Creating database: RtData64', Exception: java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver java.lang.ClassNotFoundException: ianywhere.ml.jdbcodbc.IDriver at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at com.wra.websira.WraDatabase.open(WraDatabase.java:64) at com.wra.websira.WraJdbc.init(WraJdbc.java:46) at com.wra.websira.WraAdmin.init(WraAdmin.java:257) at com.wra.websira.WraAdmin.validateUser(WraAdmin.java:594) at com.wra.websira.WraAdmin.validateUser(WraAdmin.java:451) at eddsrv.LoginBean.verifyUser(LoginBean.java:41) at org.apache.jsp.Login_jsp._jspService(Login_jsp.java:144) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:391) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:498) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:394) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:284) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:322) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1714) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
Re: Trouble with jdbc drivers in TC 7 - fixed
2011/4/8 David kerber dcker...@verizon.net: To close this loop, I got it fixed. The issue was a (apparently very slightly) corrupt jodbc.jar file. I say very slightly because I could open it with windows explorer's .zip handling functionality and everything looked fine, but tomcat choked on it when trying to open it with java.util.zip. Tomcat was throwing exceptions at startup, but they were quite a bit further up in the log from the one I posted here, and I didn't see them for the longest time. Congratulations. Were the messages clear enough, or maybe something may need improving there? The CNFE was due to the .jar containing the class not being opened because of the unzipping error. Reinstalling the software update got me a good .jar file, and now it all works. Thanks for your patience! D Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with jdbc drivers in TC 7 - fixed
On 4/7/2011 5:57 PM, Konstantin Kolinko wrote: 2011/4/8 David kerberdcker...@verizon.net: To close this loop, I got it fixed. The issue was a (apparently very slightly) corrupt jodbc.jar file. I say very slightly because I could open it with windows explorer's .zip handling functionality and everything looked fine, but tomcat choked on it when trying to open it with java.util.zip. Tomcat was throwing exceptions at startup, but they were quite a bit further up in the log from the one I posted here, and I didn't see them for the longest time. Congratulations. Were the messages clear enough, or maybe something may need improving there? The error message was fine, once I actually saw it. It was just quite a ways up the log file from the final exception that I originally posted. Once I saw the startup error, it's obvious that the CNFE was just a cascading error from the root problem. The only thing I question is whether java.util.zip might be too picky, and failing to open .jar files that could have actually been usable. Windows had no trouble unzipping the .jar. That's obviously an Oracle issue, though, and not a Tomcat one. Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with jdbc drivers in TC 7 - fixed
2011/4/8 David Kerber dcker...@verizon.net: On 4/7/2011 5:57 PM, Konstantin Kolinko wrote: 2011/4/8 David kerberdcker...@verizon.net: To close this loop, I got it fixed. The issue was a (apparently very slightly) corrupt jodbc.jar file. I say very slightly because I could open it with windows explorer's .zip handling functionality and everything looked fine, but tomcat choked on it when trying to open it with java.util.zip. Tomcat was throwing exceptions at startup, but they were quite a bit further up in the log from the one I posted here, and I didn't see them for the longest time. Congratulations. Were the messages clear enough, or maybe something may need improving there? The error message was fine, once I actually saw it. It was just quite a ways up the log file from the final exception that I originally posted. Once I saw the startup error, it's obvious that the CNFE was just a cascading error from the root problem. The only thing I question is whether java.util.zip might be too picky, and failing to open .jar files that could have actually been usable. Windows had no trouble unzipping the .jar. That's obviously an Oracle issue, though, and not a Tomcat one. If a jar is truncated I wouldn't call it useful, and it is better to fail early. IIRC,in zip format there is header for each zipped entry, plus a master index at the end. Reading the archive sequentially vs. accessing a random file will be implemented differently. And it looks as if Windows integrated support of zip files is loose in error handling. (A thing to beware if anyone will encounter the same issue as you did). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Trouble with jdbc drivers in TC 7 - fixed
On 4/7/2011 8:02 PM, Konstantin Kolinko wrote: 2011/4/8 David Kerberdcker...@verizon.net: On 4/7/2011 5:57 PM, Konstantin Kolinko wrote: 2011/4/8 David kerberdcker...@verizon.net: To close this loop, I got it fixed. The issue was a (apparently very slightly) corrupt jodbc.jar file. I say very slightly because I could open it with windows explorer's .zip handling functionality and everything looked fine, but tomcat choked on it when trying to open it with java.util.zip. Tomcat was throwing exceptions at startup, but they were quite a bit further up in the log from the one I posted here, and I didn't see them for the longest time. Congratulations. Were the messages clear enough, or maybe something may need improving there? The error message was fine, once I actually saw it. It was just quite a ways up the log file from the final exception that I originally posted. Once I saw the startup error, it's obvious that the CNFE was just a cascading error from the root problem. The only thing I question is whether java.util.zip might be too picky, and failing to open .jar files that could have actually been usable. Windows had no trouble unzipping the .jar. That's obviously an Oracle issue, though, and not a Tomcat one. If a jar is truncated I wouldn't call it useful, and it is better to fail early. IIRC,in zip format there is header for each zipped entry, plus a master index at the end. Reading the archive sequentially vs. accessing a random file will be implemented differently. And it looks as if Windows integrated support of zip files is loose in error handling. (A thing to beware if anyone will encounter the same issue as you did). Windows is well known to have issues in its .zip handling, especially with large files. I have seen many times where windows would demand a password for a .zip file, when one was not actually required. Switching to a real unzipper like 7zip or equivalent fixed the problem. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
