Strange PATH behaviour in java 1.5.0.02?

[sparhawk]

I tried to access a lotus database from within java (Using Eclipse 3.2
as my IDE) and when I run my application with the smallest possible
sample that I could find, I always got an error telling me that the
nlsxbe.dll couldn't be found in the java library path.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no nlsxbe in
java.library.path

Since I know that this library is in my Notes application directory, I
pointed my PATH there, expecting it to resolve this issue but it
didn't. I did a lot of googling about this, but all help that I could
find was saying that my PATH was not set properly. This was not the
issue though because I also printed the PATH variable from within the
java application and I could see that the path correct. I also set the
java.library.path variable and this also didn't work. Finally I
analyzed the problem with the FileMon utillity (from winternals.com)
and then I found out whats wrong. This tool monitors all filesystem
activity on the driver level. With this I could see that javaw tries to
open the dll in C:\Programme\java\java_1.5.0_02\bin path which is my
installation directory for Java. The question is why? Now that I found
this path, I copied the dll over and now it works. But this is not a
good solution, because this DLL is part of Notes and shouldn't have to
be copied in all kind of places. The question is, why does java ignore
all the system paths and only reads from there? This looks either as if
the path is somehow screwed up or that javaw sets it's own execution
environment. Or does javaw has it's own configuration, so that I have
to set the PATH there?
For now it works, but I would rather have a cleaner solution than this-

Thanks for any hints!

 

[whunmr]

try this

http://groups.google.com/group/comp...d0b26a93dfb/e4738d69ad48f894#e4738d69ad48f894

 

[Chris Uppal]

I tried to access a lotus database from within java (Using Eclipse 3.2
as my IDE) [...]

Does your code work when you run java from the command line ? I.e. is this a
problem with your machine's set-up, or something weird that Eclipse is doing ?

Since I know that this library is in my Notes application directory, I
pointed my PATH there, expecting it to resolve this issue but it
didn't.

Assuming that the program doesn't work from the command-line, it would seem
that you have set the %Path% wrong in some way. Perhaps you have used quotes,
or misspelled something ? Worth double checking....

Finally I
analyzed the problem with the FileMon utillity (from winternals.com)
and then I found out whats wrong. This tool monitors all filesystem
activity on the driver level.

A good move.

With this I could see that javaw tries to
open the dll in C:\Programme\java\java_1.5.0_02\bin path which is my
installation directory for Java. The question is why?

Well, it /should/ look there -- it should always look in it's own directory
first (that's how Windows works). The question is, what did it do /after/ it
had failed to open the DLL from its own directory. If it tried somewhere else
(as it should have done, several somewhere elses in fact), then were any of
them more-or-less the same as your Notes directory. If so then it's presumably
a typo; if not then Something Very Odd is happening...

The java[w] programs don't have any special provision for ignoring the system
%Path% that I know of. It might be worth posting the text of your
loadLibrary() call -- presumably you are just doing (correctly)
System.loadLibrary("nlsxbe"), or the equivalent using Runtime, or it wouldn't
work when you copy the DLL into the Java bin directory, but maybe there's
something odd there.

-- chris

 

[sparhawk]

Does your code work when you run java from the command line ? I.e. is this a
problem with your machine's set-up, or something weird that Eclipse is doing ?

Yes. It runs fine. After some additional testing we noticed that this
only happens when run from inside Eclipse.

Assuming that the program doesn't work from the command-line, it would seem
that you have set the %Path% wrong in some way. Perhaps you have used quotes,
or misspelled something ? Worth double checking....

It's definitely correct.

Well, it /should/ look there -- it should always look in it's own directory
first (that's how Windows works). The question is, what did it do /after/ it
had failed to open the DLL from its own directory. If it tried somewhere else
(as it should have done, several somewhere elses in fact), then were any of
them more-or-less the same as your Notes directory. If so then it's presumably
a typo; if not then Something Very Odd is happening...

It looks nowhere else. It tries to open it frmo there and if that fails
I get the errormessage.

The java[w] programs don't have any special provision for ignoring the system
%Path% that I know of. It might be worth posting the text of your
loadLibrary() call -- presumably you are just doing (correctly)
System.loadLibrary("nlsxbe"), or the equivalent using Runtime, or it wouldn't
work when you copy the DLL into the Java bin directory, but maybe there's
something odd there.

I also tried loading it like this but it only worked either when I put
the full pathname. Using PATH did not work from inside Eclipse.

 

[Chris Uppal]

sparhawk wrote:

[me:]

Yes. It runs fine. After some additional testing we noticed that this
only happens when run from inside Eclipse.

Then Eclipse is presumably setting the %Path% environment variable for the
child process it spawns to run the javaw program. That should certainly be
something you can tell it not to do (or modify it anyway), but I don't know
what the relevant option would be. Perhaps one of the obscure pages of the
run/debug settup dialog.

You could use Process Explorer (also from SysInternals) to see what environment
and command-line parameters Eclipse has used to launch javaw.exe. That might
offer some insight.

The java[w] programs don't have any special provision for ignoring the
system %Path% that I know of. It might be worth posting the text of
your loadLibrary() call -- presumably you are just doing (correctly)
System.loadLibrary("nlsxbe"), or the equivalent using Runtime, or it
wouldn't work when you copy the DLL into the Java bin directory, but
maybe there's something odd there.

I also tried loading it like this but it only worked either when I put
the full pathname. Using PATH did not work from inside Eclipse.

Do you mean that it works if you use the full pathname from inside Eclipse and
from the command-line, but that if you just use "nlsxbe" then that only works
from the command-line ?

-- chris

 

[Thomas Antepoth]

Hi there,


we might swap our problems. The case is quite the opposite here.

When the jar is run from the commandline the nlsxbe is not found despite the
nlsxbe.dll is perfectly located in the search path. But when the agent is
run in Eclipse as well as in Notes R5 it runs perfectly.

The JRE used here is 1.5.0_04. This behavior is seen as well in the SDK.

Thanks to your posting I was able to see the same PATH-weirdness in filemon too.

The java.exe just looks into it's jre/bin/ directory to open the DLL and
just fails without looking into any other directory in its java.library.path.

I also checked the java.security and the java.policy for any restrictions
but to no avail.

Yes. It runs fine. After some additional testing we noticed that this only
happens when run from inside Eclipse.

How do you call your program? Would you mind to post the commandline here,
please?

Here's the contents of the .settings/ used to get the agents running in the
project here.

== cut ==
$ cat org.eclipse.jdt.core.prefs
#Wed Jan 25 15:30:13 CET 2006
eclipse.preferences.version=1
org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.1
org.eclipse.jdt.core.compiler.codegen.unusedLocal=preserve
org.eclipse.jdt.core.compiler.compliance=1.3
org.eclipse.jdt.core.compiler.debug.lineNumber=generate
org.eclipse.jdt.core.compiler.debug.localVariable=generate
org.eclipse.jdt.core.compiler.debug.sourceFile=generate
org.eclipse.jdt.core.compiler.problem.assertIdentifier=ignore
org.eclipse.jdt.core.compiler.problem.enumIdentifier=ignore
org.eclipse.jdt.core.compiler.source=1.3

$ cat org.eclipse.jdt.ui.prefs
#Thu Feb 23 11:24:23 CET 2006
eclipse.preferences.version=1
internal.default.compliance=user
org.eclipse.jdt.ui.text.custom_code_templates=<?xml version\="1.0" encoding\="UTF-8"?><templates/>

== cut ==

The notes.jar is bound as an "external library" in the compile settings on
top of all libraries used.

I also tried loading it like this but it only worked either when I put the
full pathname. Using PATH did not work from inside Eclipse.

AFAIK the notes.jar is responsible to do the loadLibrary() call.


t++