[izpack-users] 3.8.1: Custom Actions - Ant: Nativedlls not available in java library path
Bartz, Klaus
Klaus.Bartz at coi.de
Mon Jun 19 10:29:43 CEST 2006
Hi René,
natives with an installation are not so easy as natives in a
well installed environment.
One rule of IzPack is to clean up all things which are used only
by the installation.
An other rule is to put all needed into one jar file.
Therefore dlls are stored in the jar and written out with a
temp name as needed. Because this the mimik via Librarian;
it triggers the outloading. But with some ant tasks
(if you allow fork because you need a java compiler from
tools.jar) you are in an other process where Librarian not
exist.
What is the path of "win32jni.dll"? If you use ant after install
you can declare a variable for ant where the path of win32jni.dll
is stored and load the dll with path. How to do it you can see
in Librarian.java.
One "trick" is to use System.load instead of System.loadLibrary
where you can use the full path.
Additional AntActionInstallerListener should be a workable
example for an InstallerListener. Not less, but also not more.
I have spend many time to made it passably generic. In the moment
I have not the time to add native support in a generic way to it.
Will be nice if you can do it. But only in the Listener and its
dependants, not in the common IzPack part.
May be the best will be you write a "base" ant class for it
which makes the load.
Cheers
Klaus
>-----Original Message-----
>From: izpack-users-admin at berlios.de
>[mailto:izpack-users-admin at berlios.de]On Behalf Of René Krell
>Sent: Friday, June 16, 2006 2:23 PM
>To: izpack-users at berlios.de
>Subject: ***SPAM*** Re: [izpack-users] 3.8.1: Custom Actions - Ant:
>Nativedlls not available in java library path
>
>
>I solved the problem by my own according to the recommendations at
>http://openfacts.berlios.de/index-en.phtml?title=IzPack/Undocum
>entedFeatures:
>---
>Native libraries
>If you add some jar that used custom code, and use the
><native> tag, don't use
>System.load or System.loadLibrary in order to load the native
>library. Use
>instead this:
> Librarian.getInstance().loadLibrary(
> "myNativeLibWithoutExtension",
> nativeLibraryClient)
>where:
>com.izforge.izpack.util.Librarian is a class supplied with IzPack.
>nativeLibraryClient is an object belonging to a class implementing the
>NativeLibraryClient interface.
>---
>
>The problem was that System.loadLibrary does not work during
>custom Ant
>actions in own Ant tasks (due to a missing system property
>java.library.path
>or environment variable LD_LIBRARY_PATH).
>The Librarian refers to a System.load which requires an
>absolute path to the
>native library instead.
>
>Nevertheless, this is a workaround and in future it would be
>nice to have
>System.loadLibrary working for custom Ant actions in own Ant
>tasks, too, as
>long as the <native> tag is declared and the referred file is
>provided. At
>least there could be overgiven some system property
>java.library.path or so
>when calling Ant(?).
>Otherwise I'd always have to add izpack jars to their
>classpath to use the
>Librarian and all depending classes.
>
>René
>
>
>On Tuesday 13 June 2006 15:32, René Krell wrote:
>> On launching my self compiled installation jar, I get
>> an "java.lang.UnsatisfiedLinkError: no win32jni in
>java.library.path" (see:
>> stacktrace.log) when launching a custom Ant install action,
>even though I
>> declared the appropriate DLL in my install.xml:
>>
>> <native type="3rdparty" name="win32jni.dll"/>
>>
>> Questions:
>> 1. Is it possible to use links to native libraries from
>custom Ant actions
>> at all?
>> 2a. Where is the right place to declare them (if I need them only at
>> install time)?
>> 3b. or ... How can I set the according properties probably
>needed for this
>> and given to the Ant launcher as -Djava.library.path (and
>user variables,
>> as LD_LIBRARY_PATH)? Are they set automatically by the installer?
>>
>> Thanks,
>> René
>_______________________________________________
>izpack-users mailing list
>izpack-users at lists.berlios.de
>http://lists.berlios.de/mailman/listinfo/izpack-users
>
More information about the izpack-users
mailing list