Chris Uppal schrieb:
> 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 - 27 Jul 2006 09:32 GMT
[me:]
> > 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.
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
[quoted text clipped - 5 lines]
> 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 - 02 Aug 2006 08:58 GMT
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.
>> 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.
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.
>> 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.
AFAIK the notes.jar is responsible to do the loadLibrary() call.
t++