Re: java.lang.UnsatisfiedLinkError: running tomcat on java headless?
.1 (libc6,x86-64) => /usr/lib/libexpatw.so.1 libexpat.so.1 (libc6,x86-64) => /usr/lib/libexpat.so.1 libept.so.0 (libc6,x86-64) => /usr/lib/libept.so.0 libedit.so.2 (libc6,x86-64) => /usr/lib/libedit.so.2 libdns.so.45 (libc6,x86-64) => /usr/lib/libdns.so.45 libdl.so.2 (libc6,x86-64, OS ABI: Linux 2.6.8) => /lib/libdl.so.2 libdirectfb-1.0.so.0 (libc6,x86-64) => /usr/lib/libdirectfb-1.0.so.0 libdirect-1.0.so.0 (libc6,x86-64) => /usr/lib/libdirect-1.0.so.0 libdevmapper.so.1.02.1 (libc6,x86-64) => /lib/libdevmapper.so.1.02.1 libdes425.so.3 (libc6,x86-64) => /usr/lib/libdes425.so.3 libdbus-1.so.3 (libc6,x86-64) => /usr/lib/libdbus-1.so.3 libdb-4.6.so (libc6,x86-64) => /usr/lib/libdb-4.6.so libdb-4.5.so (libc6,x86-64) => /usr/lib/libdb-4.5.so libdatrie.so.0 (libc6,x86-64) => /usr/lib/libdatrie.so.0 libdaemon.so.0 (libc6,x86-64) => /usr/lib/libdaemon.so.0 libcwidget.so.3 (libc6,x86-64) => /usr/lib/libcwidget.so.3 libcups.so.2 (libc6,x86-64) => /usr/lib/libcups.so.2 libctutils.so.0 (libc6,x86-64) => /lib/libctutils.so.0 libcrypto.so.0.9.8 (libc6,x86-64) => /usr/lib/libcrypto.so.0.9.8 libcrypt.so.1 (libc6,x86-64, OS ABI: Linux 2.6.8) => /lib/libcrypt.so.1 libconsole.so.0 (libc6,x86-64) => /lib/libconsole.so.0 libcom_err.so.2 (libc6,x86-64) => /lib/libcom_err.so.2 libcidn.so.1 (libc6,x86-64, OS ABI: Linux 2.6.8) => /lib/libcidn.so.1 libcfont.so.0 (libc6,x86-64) => /lib/libcfont.so.0 libcap.so.2 (libc6,x86-64) => /lib/libcap.so.2 libcap.so.1 (libc6,x86-64) => /lib/libcap.so.1 libcairo.so.2 (libc6,x86-64) => /usr/lib/libcairo.so.2 libc.so.6 (libc6,x86-64, OS ABI: Linux 2.6.8) => /lib/libc.so.6 libbz2.so.1.0 (libc6,x86-64) => /lib/libbz2.so.1.0 libblkid.so.1 (libc6,x86-64) => /lib/libblkid.so.1 libbind9.so.40 (libc6,x86-64) => /usr/lib/libbind9.so.40 libavahi-core.so.5 (libc6,x86-64) => /usr/lib/libavahi-core.so.5 libavahi-common.so.3 (libc6,x86-64) => /usr/lib/libavahi-common.so.3 libattr.so.1 (libc6,x86-64) => /lib/libattr.so.1 libatk-1.0.so.0 (libc6,x86-64) => /usr/lib/libatk-1.0.so.0 libasound.so.2 (libc6,x86-64) => /usr/lib/libasound.so.2 libapt-pkg-libc6.7-6.so.4.6 (libc6,x86-64) => /usr/lib/libapt-pkg-libc6.7-6.so.4.6 libapt-inst-libc6.7-6.so.1.1 (libc6,x86-64) => /usr/lib/libapt-inst-libc6.7-6.so.1.1 libanl.so.1 (libc6,x86-64, OS ABI: Linux 2.6.8) => /lib/libanl.so.1 libacl.so.1 (libc6,x86-64) => /lib/libacl.so.1 libX11.so.6 (libc6,x86-64) => /usr/lib/libX11.so.6 libXtst.so.6 (libc6,x86-64) => /usr/lib/libXtst.so.6 libXt.so.6 (libc6,x86-64) => /usr/lib/libXt.so.6 libXrender.so.1 (libc6,x86-64) => /usr/lib/libXrender.so.1 libXrandr.so.2 (libc6,x86-64) => /usr/lib/libXrandr.so.2 libXp.so.6 (libc6,x86-64) => /usr/lib/libXp.so.6 libXmuu.so.1 (libc6,x86-64) => /usr/lib/libXmuu.so.1 libXinerama.so.1 (libc6,x86-64) => /usr/lib/libXinerama.so.1 libXi.so.6 (libc6,x86-64) => /usr/lib/libXi.so.6 libXft.so.2 (libc6,x86-64) => /usr/lib/libXft.so.2 libXfont.so.1 (libc6,x86-64) => /usr/lib/libXfont.so.1 libXfixes.so.3 (libc6,x86-64) => /usr/lib/libXfixes.so.3 libXext.so.6 (libc6,x86-64) => /usr/lib/libXext.so.6 libXdmcp.so.6 (libc6,x86-64) => /usr/lib/libXdmcp.so.6 libXdamage.so.1 (libc6,x86-64) => /usr/lib/libXdamage.so.1 libXcursor.so.1 (libc6,x86-64) => /usr/lib/libXcursor.so.1 libXcomposite.so.1 (libc6,x86-64) => /usr/lib/libXcomposite.so.1 libXau.so.6 (libc6,x86-64) => /usr/lib/libXau.so.6 libSegFault.so (libc6,x86-64, OS ABI: Linux 2.6.8) => /lib/libSegFault.so libSM.so.6 (libc6,x86-64) => /usr/lib/libSM.so.6 libICE.so.6 (libc6,x86-64) => /usr/lib/libICE.so.6 libBrokenLocale.so.1 (libc6,x86-64, OS ABI: Linux 2.6.8) => /lib/libBrokenLocale.so.1 ld-linux-x86-64.so.2 (libc6,x86-64) => /lib/ld-linux-x86-64.so.2 but I still don't know how to check the value of java.library.path and how to run servlets from command line. Michael Ludwig-4 wrote: > > method8 schrieb: >> - But what about libmlib_image.so? That's the one it's complaining >> about. >> >> I can see that as well. > > So check the value of "java.library.path". Just to be sure. > >> Could it be it's just Debian the problem? I develop on windows and >> deploy on a debian machine, and had some problems in the past with >> policies and socket permissions. > > Try running your Itext examples from the com
Re: java.lang.UnsatisfiedLinkError: running tomcat on java headless?
- But what about libmlib_image.so? That's the one it's complaining about. I can see that as well. This is the whole list of files in /usr/lib/jvm/java-1.5.0-sun-1.5.0.18/jre/lib/amd64 awt_robot libcmm.so libinstrument.so libjava.so libjsig.solibnative_chmod.so librmi.so motif21 gtkhelper libdcpr.so libioser12.solibjawt.so libjsoundalsa.so libnet.so libsaproc.so native_threads headless libdt_socket.solibj2pkcs11.so libJdbcOdbc.so libjsound.so libnio.so libunpack.so server jvm.cfglibfontmanager.so libjaas_unix.so libjdwp.so libmanagement.so libodbcinst.so libverify.so xawt libawt.so libhprof.solibjava_crw_demo.so libjpeg.so libmlib_image.so libodbc.so libzip.so Could it be it's just Debian the problem? I develop on windows and deploy on a debian machine, and had some problems in the past with policies and socket permissions. -- View this message in context: http://www.nabble.com/java.lang.UnsatisfiedLinkError%3A-running-tomcat-on-java-headless--tp25220313p25221584.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
java.lang.UnsatisfiedLinkError: running tomcat on java headless?
Dear all, I'm using the iText library to generate pdfs from a database on the fly. Whenever I use some of it's features that require simple things like java.awt.Color, I get an java.lang.UnsatisfiedLinkError as shown: java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-1.5.0-sun-1.5.0.18/jre/lib/amd64/libawt.so: libmlib_image.so: cannot open shared object file: No such file or directory at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1668) at java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.lang.System.loadLibrary(System.java:993) at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50) at java.security.AccessController.doPrivileged(Native Method) at java.awt.Toolkit.loadLibraries(Toolkit.java:1509) at java.awt.Toolkit.(Toolkit.java:1530) at java.awt.Color.(Color.java:250) at tablereport.processRequest(tablereport.java:55) at tablereport.doGet(tablereport.java:130) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke (StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke (StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection (Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt (LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) After some research and verifying that libawt.so physically exists I read somewhere that whenever java is installed no a linux box without x (in my case it's a remote vps) java omits certain graphics related libraries like AWT (naturally). I also read that you can run java headless to avoid the dependencies to X. Now is there a way to run tomcat (or add variables to tomcat's startup.sh) to avoid having these dependencies? Thanks for your help, William -- View this message in context: http://www.nabble.com/java.lang.UnsatisfiedLinkError%3A-running-tomcat-on-java-headless--tp25220313p25220313.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
