Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
Martin Gainty schrieb am 01.02.2009 um 22:42:59 (-0500): saw this in the 2.2.69 readme.txt did you use cscript to config the environment? Version 2.2.69 of what? Anyway, Berkeley DB XML on Windows is built using a Visual Studio project file. cscript configure.js help No such thing in the source tree. Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
Caldarale, Charles R schrieb am 01.02.2009 um 22:38:57 (-0600): From: Michael Ludwig [mailto:mil...@gmx.de] Subject: Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) The Java bridge DLLs (or whatever they're called) can be moved to a directory only contained in java.library.path, but not in PATH. The other libraries must be in a PATH directory in order to be loaded. If I'm interpreting your posting correctly, it looks like you have discovered that the other DLLs are not being loaded by the JVM, but rather indirectly, due to references from the ones the JVM loads. Sort of. I knew before that the Java bridge libraries would load the other ones, but I didn't know it would matter. I thought that under the hood, java.library.path would be equivalent to setting PATH, so I didn't understand that one would fail where the other wouldn't. If you really wanted to keep them all under java.library.path, you could write some initialization code for your webapp that does loadLibrary() calls on the previously indirectly loaded ones; I see, System.loadLibrary(). Never used that before. but it's probably simpler just to keep them visible in PATH. I think so, too. Thanks for your help and advice in dealing with this. Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
i downloaded libxml and dont see any Visual Studio project files (assuming they are *.ds?) ..although I see makefiles in \win32 folder can you provide the link where you acquired the source? thanks/ Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Mon, 2 Feb 2009 23:35:26 +0100 From: mil...@gmx.de To: users@tomcat.apache.org Subject: Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) Martin Gainty schrieb am 01.02.2009 um 22:42:59 (-0500): saw this in the 2.2.69 readme.txt did you use cscript to config the environment? Version 2.2.69 of what? Anyway, Berkeley DB XML on Windows is built using a Visual Studio project file. cscript configure.js help No such thing in the source tree. Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org _ Windows Live™: E-mail. Chat. Share. Get more ways to connect. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_012009
Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
Martin Gainty schrieb am 02.02.2009 um 17:45:42 (-0500): i downloaded libxml and dont see any Visual Studio project files (assuming they are *.ds?) ..although I see makefiles in \win32 folder That's a misunderstanding - I was talking about Berkeley DB XML, which is an XML extension to the Berkeley Database. can you provide the link where you acquired the source? Here's the product homepage with a download link: Oracle Berkeley DB XML http://www.oracle.com/database/berkeley-db/xml/index.html Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
Caldarale, Charles R schrieb am 29.01.2009 um 22:45:40 (-0600): From: Michael Ludwig [mailto:mil...@gmx.de] Subject: Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) -Djava.library.path=C:\Server;C:\src\BerkeleyDbXml\dbxml-2.4.1 6\bin\debug;... Is *src* really the right place to find the DLLs? Hi Charles. Yes, it is. I created C:\src to put source code there. I compiled that souce code, and the DLLs go to the bin\debug subdirectory. I realize it's long, but can you post the full string? Trying to reproduce this error, I noticed to my surprise that it wouldn't occur. It turns out that the error only occurs for some of the DLLs. libdb_java46d.dll # can be in java.library.path or PATH libdbxml_java24d.dll # ditto libdb46d.dll # must reside in a PATH directory libdbxml24d.dll # ditto xerces-c_2_8D.dll # ditto xqilla21d.dll # ditto The Java bridge DLLs (or whatever they're called) can be moved to a directory only contained in java.library.path, but not in PATH. The other libraries must be in a PATH directory in order to be loaded. So I guess there is something wrong with Tomcat here. So I now guess I was wrong here, and of course you were right. Sorry for blaming Tomcat. The problem seems to be with how the libdb(xml)_java libraries load other libraries. So this is probably related to BDB and the Windows API, or the build - but not to Tomcat. I can't see how, unless there's something really odd going on with the classloader hierarchy. Can you post the full stack trace of the UnsatisfiedLinkError? I wonder if there's a custom classloader that's getting in the way, since I don't have any problems with Tomcat's set of classloaders accessing native libraries specified by the java.library.path setting. Here's a stack trace, in case you still think it is relevant. The error message mentions the *_java library, but I think this is only because that library has a dependency on the libdb46, and that one isn't found, which the error message does not reveal. Michael Ludwig 22.01.2009 23:14:12 org.apache.catalina.core.StandardContext listenerStart SCHWERWIEGEND: Exception sending context initialized event to listener instance of class milu.dbxml.DbXmlInitExit java.lang.UnsatisfiedLinkError: no libdb_java46 in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1709) at java.lang.Runtime.loadLibrary0(Runtime.java:823) at java.lang.System.loadLibrary(System.java:1030) at com.sleepycat.db.internal.db_javaJNI.clinit(db_javaJNI.java:38) at com.sleepycat.db.internal.DbEnv.init(DbEnv.java:264) at com.sleepycat.db.EnvironmentConfig.createEnvironment(EnvironmentConfig.java:1023) at com.sleepycat.db.EnvironmentConfig.openEnvironment(EnvironmentConfig.java:976) at com.sleepycat.db.Environment.init(Environment.java:29) at milu.dbxml.DbXmlInitExit.contextInitialized(DbXmlInitExit.java:34) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:926) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:889) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h
RE: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
saw this in the 2.2.69 readme.txt did you use cscript to config the environment? 1.2 Configuring The Source -- The configuration script accepts numerous options. Some of these affect features which will be available in the compiled software, others affect the way the software is built and installed. To see a full list of options supported by the configuration script, run cscript configure.js help ? Martin __ Disclaimer and confidentiality note Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Mon, 2 Feb 2009 02:51:34 +0100 From: mil...@gmx.de To: users@tomcat.apache.org Subject: Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) Caldarale, Charles R schrieb am 29.01.2009 um 22:45:40 (-0600): From: Michael Ludwig [mailto:mil...@gmx.de] Subject: Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) -Djava.library.path=C:\Server;C:\src\BerkeleyDbXml\dbxml-2.4.1 6\bin\debug;... Is *src* really the right place to find the DLLs? Hi Charles. Yes, it is. I created C:\src to put source code there. I compiled that souce code, and the DLLs go to the bin\debug subdirectory. I realize it's long, but can you post the full string? Trying to reproduce this error, I noticed to my surprise that it wouldn't occur. It turns out that the error only occurs for some of the DLLs. libdb_java46d.dll # can be in java.library.path or PATH libdbxml_java24d.dll # ditto libdb46d.dll # must reside in a PATH directory libdbxml24d.dll # ditto xerces-c_2_8D.dll # ditto xqilla21d.dll # ditto The Java bridge DLLs (or whatever they're called) can be moved to a directory only contained in java.library.path, but not in PATH. The other libraries must be in a PATH directory in order to be loaded. So I guess there is something wrong with Tomcat here. So I now guess I was wrong here, and of course you were right. Sorry for blaming Tomcat. The problem seems to be with how the libdb(xml)_java libraries load other libraries. So this is probably related to BDB and the Windows API, or the build - but not to Tomcat. I can't see how, unless there's something really odd going on with the classloader hierarchy. Can you post the full stack trace of the UnsatisfiedLinkError? I wonder if there's a custom classloader that's getting in the way, since I don't have any problems with Tomcat's set of classloaders accessing native libraries specified by the java.library.path setting. Here's a stack trace, in case you still think it is relevant. The error message mentions the *_java library, but I think this is only because that library has a dependency on the libdb46, and that one isn't found, which the error message does not reveal. Michael Ludwig 22.01.2009 23:14:12 org.apache.catalina.core.StandardContext listenerStart SCHWERWIEGEND: Exception sending context initialized event to listener instance of class milu.dbxml.DbXmlInitExit java.lang.UnsatisfiedLinkError: no libdb_java46 in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1709) at java.lang.Runtime.loadLibrary0(Runtime.java:823) at java.lang.System.loadLibrary(System.java:1030) at com.sleepycat.db.internal.db_javaJNI.clinit(db_javaJNI.java:38) at com.sleepycat.db.internal.DbEnv.init(DbEnv.java:264) at com.sleepycat.db.EnvironmentConfig.createEnvironment(EnvironmentConfig.java:1023) at com.sleepycat.db.EnvironmentConfig.openEnvironment(EnvironmentConfig.java:976) at com.sleepycat.db.Environment.init(Environment.java:29) at milu.dbxml.DbXmlInitExit.contextInitialized(DbXmlInitExit.java:34) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:926) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:889) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.start
RE: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
From: Michael Ludwig [mailto:mil...@gmx.de] Subject: Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) The Java bridge DLLs (or whatever they're called) can be moved to a directory only contained in java.library.path, but not in PATH. The other libraries must be in a PATH directory in order to be loaded. If I'm interpreting your posting correctly, it looks like you have discovered that the other DLLs are not being loaded by the JVM, but rather indirectly, due to references from the ones the JVM loads. If you really wanted to keep them all under java.library.path, you could write some initialization code for your webapp that does loadLibrary() calls on the previously indirectly loaded ones; but it's probably simpler just to keep them visible in PATH. But I suspect you have already figured that out... - 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: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
From: Michael Ludwig [mailto:mil...@gmx.de] Subject: Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) -Djava.library.path=C:\Server;C:\src\BerkeleyDbXml\dbxml-2.4.1 6\bin\debug;... Is *src* really the right place to find the DLLs? I realize it's long, but can you post the full string? Where you see ... I can see what looks like the value of my PATH. Can you post the full version of that as well? Plus, in my case, C:\WINDOWS\Sun\Java\bin. Shouldn't matter, as this doesn't exist. Yes, I now realize I get that too, when Tomcat is run as a service (I don't have such a directory either). I presume the tomcat6.exe launcher adds it for prehistoric reasons. So I guess there is something wrong with Tomcat here. I can't see how, unless there's something really odd going on with the classloader hierarchy. Can you post the full stack trace of the UnsatisfiedLinkError? I wonder if there's a custom classloader that's getting in the way, since I don't have any problems with Tomcat's set of classloaders accessing native libraries specified by the java.library.path setting. - 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: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
Konstantin Kolinko schrieb am 23.01.2009 um 04:57:31 (+0300): I think that the answer is (and your solution proves this) that the statement that service does not need environment variables is not 100% true. That is, if you compare *.bat/*.sh with how the service is started, you can see that *.bat/*.sh processes some env variables and builds up a java -jar command from those variables. Thanks for your help, Konstantin. Yes, I can see the command is built up in catalina.bat, although there is no -jar option in my version 6.0.18. The service launcher from the other hand, launches that jar directly, thus you have to configure all the arguments explicitly, and not relying on the env variables. It is those vars that are not needed. If I remember correctly, the PATH variable is respected by the Win32 API that loads the dll libraries. Thus the behavior that you had to include that folder into the PATH. Win32 API help should provide more information. http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx Yes, the second of these docs mentions the PATH environment variable is searched in order to load, failing all other possibilities. Thanks, Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
Caldarale, Charles R schrieb am 22.01.2009 um 21:52:36 (-0600): From: Michael Ludwig [mailto:mil...@gmx.de] Subject: Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) If you don't mind running another experiment, please start Tomcat as a service once with and once without the -Djava.library.path setting in the Java tab of tomcat6w.exe, and use LambdaProbe or JConsole to examine the system properties. I'm connected to the Tomcat service via JConsole 1.6.0_11. On the VM Summary tab, I can see the following for Library path: -Djava.library.path=C:\Server;C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug;... (I shortened it a bit.) This is what I specified in the Java tab of tomcat6w, and is also reflected among the VM arguments in JConsole. Now I'm going to take that away, restart the service, reconnect and see. First thing to notice is that the server starts fine, including the context sporting a ServletContextListener dependent on the Berkeley DbXml library. The library definitely loads fine. Now pasting the same thing as before: C:\Server\apache-tomcat-6.0.18\bin;.;C:\WINDOWS\Sun\Java\bin;... Where you see ... I can see what looks like the value of my PATH. After the other day's reboot, it includes the Berkeley DbXml directory. If -Djava.library.path is not set, you should see the system property set to the PATH value prefixed with Tomcat's bin directory and the current directory (.); Plus, in my case, C:\WINDOWS\Sun\Java\bin. Shouldn't matter, as this doesn't exist. if -Djava.library.path is set, the system property should be just the value from the -D. That's precisely what I'm seeing. Another test: I move one of the DLLs to another directory, C:\TempLib, and include it in java.library.path, but it won't be in PATH. And this doesn't work: Error listenerStart on startup, the context in question isn't loaded, although C:\TempLib is included in both the VM arguments and the Library path. So I guess there is something wrong with Tomcat here. Thanks for your help! Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
Konstantin Kolinko schrieb am 22.01.2009 um 07:51:16 (+0300): 2009/1/22 Michael Ludwig mil...@gmx.de: But I'm assured by the developers that: The Java API for DB XML begins by first trying to load the release versions of the libraries, and failing that then tries to load the debug versions. If it fails to find both versions then the UnsatisfiedLinkError is thrown listing the release library, even though it did look for the debug library. Should be relatively easy to check: try to reproduce the error with release versions of those libraries. Thanks Konstantin. Hmm. I tried to build the release versions (in Visual C++ 2005 Express) setting Properties Configuration to Release instead of Debug. Unfortunately, however, it has produced the debug version again, and when checking the Properties, I can see that the Configuration has gone back to Debug. I don't know VS very well and I don't feel like pursuing this error now. C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debugnotepad libdb_java46d.dll This works, I can see the DLL in notepad. So the Local System account can read the files. How about other DLLs that that DLL loads? I can open those from the SYSTEM shell just as well. Other native libraries (like Oracle XE driver) load fine in the Tomcat Service. Can you run a standalone Java program that loads those libraries or run startup.bat from that command prompt window? After adding the directory in question to the PATH, both the standalone program and the Tomcat via startup.bat (which relies on the PATH) work fine from the SYSTEM shell. Also, though maybe not relevant for this very error, but for reference: http://wiki.apache.org/tomcat/HowTo#head-a4b7185ee95d0cf14a48f92c08d1eb66b561139d I'm aware of this. The JARs are made available only to the common.loader in catalina.properties. Hmm. Apparently, the directory hadn't been in the PATH the moment the SYSTEM account took a copy of it. Maybe SYSTEM doesn't read the environment again later on. It may only get to see updates to the PATH after a reboot. Or some other trick. On the other hand, Tomcat running as a service under the SYSTEM account should disregard the PATH, as far as I know and have heard so far. I did a reboot. Turns out the Tomcat service does not disregard the PATH. It needs the directory in the PATH, and *in addition* to be present in the PATH the directory has to be included in the Java property java.library.path. Nota bene, in addition to, but not in place of the PATH. So this is solved for me. But is this the correct behaviour? Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
Hi, Michael. I am glad to hear that you solved this. Hmm. Apparently, the directory hadn't been in the PATH the moment the SYSTEM account took a copy of it. Maybe SYSTEM doesn't read the environment again later on. It may only get to see updates to the PATH after a reboot. Or some other trick. On the other hand, Tomcat running as a service under the SYSTEM account should disregard the PATH, as far as I know and have heard so far. I did a reboot. Turns out the Tomcat service does not disregard the PATH. It needs the directory in the PATH, and *in addition* to be present in the PATH the directory has to be included in the Java property java.library.path. Nota bene, in addition to, but not in place of the PATH. So this is solved for me. But is this the correct behaviour? I think that the answer is (and your solution proves this) that the statement that service does not need environment variables is not 100% true. That is, if you compare *.bat/*.sh with how the service is started, you can see that *.bat/*.sh processes some env variables and builds up a java -jar command from those variables. The service launcher from the other hand, launches that jar directly, thus you have to configure all the arguments explicitly, and not relying on the env variables. It is those vars that are not needed. If I remember correctly, the PATH variable is respected by the Win32 API that loads the dll libraries. Thus the behavior that you had to include that folder into the PATH. Win32 API help should provide more information. http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
From: Michael Ludwig [mailto:mil...@gmx.de] Subject: Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) Turns out the Tomcat service does not disregard the PATH. It needs the directory in the PATH, and *in addition* to be present in the PATH the directory has to be included in the Java property java.library.path. Something's definitely wrong here; there shouldn't be any reason to have to specify the library twice. The Windows version of the JVM initialization code only looks at PATH if the java.library.path system property has not been set to anything; there's no code anywhere that I'm aware of that will concatenate PATH and java.library.path. If you don't mind running another experiment, please start Tomcat as a service once with and once without the -Djava.library.path setting in the Java tab of tomcat6w.exe, and use LambdaProbe or JConsole to examine the system properties. If -Djava.library.path is not set, you should see the system property set to the PATH value prefixed with Tomcat's bin directory and the current directory (.); if -Djava.library.path is set, the system property should be just the value from the -D. If you're seeing something different than the above, there's probably a typo somewhere, so please post what the diagnostic tools display. (Just for reference, I'm using Tomcat 6.0.18 and JDK 1.6.0_11 on Vista 64.) - 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: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
Tommy Pham schrieb am 20.01.2009 um 21:45:17 (-0800): I don't know if this is relevant to your problem or not and you didn't mention whether you're x64 or x86 of XP version. Yes, I forgot to say, this is a 32 bit system. Here's where you can get 64bit for tomcat5: http://svn.apache.org/viewvc/tomcat/connectors/trunk/procrun/bin/amd64/ and this is for tomcat6: http://svn.apache.org/viewvc/tomcat/trunk/res/procrun/amd64/ That'll be useful in the future - thanks! Regards, Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
Caldarale, Charles R schrieb am 20.01.2009 um 21:11:21 (-0600): Environment variables are not used by services, so it doesn't really matter what's in PATH. True, it only matters for the script version. Does the account the Tomcat service runs under have access to the directory of interest? Tomcat logs on as the Local System account. Opening a command prompt using an AT job to examine this (at 01:15 /interactive cmd.exe). When it opens: C:\WINDOWS\system32whoami SYSTEM C:\WINDOWS\system32cd \src\BerkeleyDbXml\dbxml-2.4.16\bin\debug C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debugnotepad libdb_java46d.dll This works, I can see the DLL in notepad. So the Local System account can read the files. Try setting -verbose:jni in the Java tab of tomcat?w.exe and see if anything interesting is displayed. Don't know exactly what to look for, but it tells mit is dynamic-linking and registering a lot of native methods, all of which are in namespaces under java, sun, com.sun, and org.apache. I guess I would have been looking for some failure related to com.sleepycat, but that is just a guess. And indeed, this works using bin\startup.cmd. We'll presume you meant bin\startup.bat. You can safely do that. :-) Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
2009/1/22 Michael Ludwig mil...@gmx.de: But I'm assured by the developers that: The Java API for DB XML begins by first trying to load the release versions of the libraries, and failing that then tries to load the debug versions. If it fails to find both versions then the UnsatisfiedLinkError is thrown listing the release library, even though it did look for the debug library. Should be relatively easy to check: try to reproduce the error with release versions of those libraries. C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debugnotepad libdb_java46d.dll This works, I can see the DLL in notepad. So the Local System account can read the files. How about other DLLs that that DLL loads? Can you run a standalone Java program that loads those libraries, or run startup.bat from that command prompt window? Also, though maybe not relevant for this very error, but for reference: http://wiki.apache.org/tomcat/HowTo#head-a4b7185ee95d0cf14a48f92c08d1eb66b561139d Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
A primitive web app sketch involving Java extensions to a native library (JNI) used up front in a ServletContextListener works when started via bin\startup.bat but doesn't work when installed as a Windows service and started via bin\tomcat6w.exe in the case of 6.0.18 or bin\tomcat5w.exe in the case of 5.5.27, on Windows XP. Here's the libraries I need: :: dir /s /b *.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\libdb46d.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\libdbxml24d.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\libdbxml_java24d.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\libdb_java46d.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\xerces-c_2_8D.dll C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug\xqilla21d.dll The directory containing these libraries *is* included in PATH. Likewise, it is included as follows on the Java tab of tomcat5w.exe: -Djava.library.path=C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug The error thrown when starting Tomcat 5 or 6 as the service with the app in question is the following: java.lang.UnsatisfiedLinkError: no libdb_java46 in java.library.path I'm checking I *really* have the bin\debug directory in the path by doing the following: System.out.println( System.getProperty( java.library.path)); ... env = new Environment( envHome, envConf); // triggers the error And I do get the relevant directory in the output. Now there is one subtlety, that you may or may not have noticed: The library I have in my directory is libdb_java46d.dll (note the d for debug version after the version number), the library name in the error message, however, is libdb_java46 (the d is missing). This had me confused and sent on the wrong tracks at first. But I'm assured by the developers that: The Java API for DB XML begins by first trying to load the release versions of the libraries, and failing that then tries to load the debug versions. If it fails to find both versions then the UnsatisfiedLinkError is thrown listing the release library, even though it did look for the debug library. Java-API in Tomcat 6: libdb_java46.dll UnsatisfiedLinkError (2.4.16+p1) http://forums.oracle.com/forums/thread.jspa?threadID=848389 And indeed, this works using bin\startup.cmd. I tried to run the service using various JVMs, but that didn't dispel the error. What could make the script version succeed and the service version fail with both Tomcat 5.5 and 6? What could I do to find the error? Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
From: Michael Ludwig [mailto:mil...@gmx.de] Subject: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) The directory containing these libraries *is* included in PATH. Environment variables are not used by services, so it doesn't really matter what's in PATH. Likewise, it is included as follows on the Java tab of tomcat5w.exe: -Djava.library.path=C:\src\BerkeleyDbXml\dbxml-2.4.16\bin\debug Good; that's where it needs to be. Does the account the Tomcat service runs under have access to the directory of interest? Try setting -verbose:jni in the Java tab of tomcat?w.exe and see if anything interesting is displayed. And indeed, this works using bin\startup.cmd. We'll presume you meant bin\startup.bat. - 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: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe)
- Original Message From: Michael Ludwig mil...@gmx.de To: Tomcat Users List users@tomcat.apache.org Sent: Tuesday, January 20, 2009 4:55:16 PM Subject: UnsatisfiedLinkError in Windows Service (tomcat6w/5w.exe) A primitive web app sketch involving Java extensions to a native library (JNI) used up front in a ServletContextListener works when started via bin\startup.bat but doesn't work when installed as a Windows service and started via bin\tomcat6w.exe in the case of 6.0.18 or bin\tomcat5w.exe in the case of 5.5.27, on Windows XP. Hi Michael, I don't know if this is relevant to your problem or not and you didn't mention whether you're x64 or x86 of XP version. I had problem of tomcat startup as service before on x64 (xp or Win03). You need to replace the tomcat*.exe w/ the 64bit version. The included *.exe are 32 bit. Here's where you can get 64bit for tomcat5: http://svn.apache.org/viewvc/tomcat/connectors/trunk/procrun/bin/amd64/ and this is for tomcat6: http://svn.apache.org/viewvc/tomcat/trunk/res/procrun/amd64/ Regards, Tommy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
