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
