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\debug>notepad 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

Reply via email to