I found some interesting reading here:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4280189
http://forum.java.sun.com/thread.jspa?threadID=707176

However, since my script will not work without the sysproperty, one of the
following must be true:

a) the described behaviour of java.library.path has changed in Tiger
b) the implementation of sysproperty uses the hack described in 707176
c) it was never true that you couldn't change java.library.pathprogrammatically

Tonight I will be downloading ANT sources from my unrestricted network
access ...

Sadly, I still do not have an elegant solution to my problem

On 14/06/06, Juan Jimenez <[EMAIL PROTECTED]> wrote:

Thank you for taking an interest.

Our tests have always been forked and I do want to avoid hacks, which is
why I am coming to this forum.

This is what I have so far ( lib.package contains all shared objects ):

<property name="junit.lib.path" value="${java.library.path}${
path.separator}${lib.package}" />
<junit failureproperty=" junit.failed"
       fork="true"
       includeAntRuntime="true"
       dir="${basedir}"
       showoutput="true">

    <classpath>
        <path refid="test.classpath"/>
    </classpath>

    <!-- we now reset java.library.path to something specific to this
project -->

    <sysproperty key="java.library.path" path="${junit.lib.path}"/>

    <!--
         However, it doesn't seem to work under Linux.  Native libraries
needed
         by Java are loaded correctly but other native libraries needed by

         native libraries loaded by Java cannot be found

         None of the following worked (aside from not being platform
independent)


    <sysproperty key="LD_LIBRARY_PATH" path="${junit.lib.path}"/>
    <env key="LD_LIBRARY_PATH" path="${ junit.lib.path}" />
    <env key="LD_LIBRARY_PATH" path="${env.LD_LIBRARY_PATH }${
path.separator}${lib.package}" />
    <env key="LD_LIBRARY_PATH" path="${ env.LD_LIBRARY_PATH}${
path.separator}${lib.package}" />

    the following also works on Windows if you also remove the sysproperty
above, however this
    is not platform independent and should be avoided
    <env key="PATH" path="${ junit.lib.path}" />
    -->

    <formatter type="xml"/>
    <formatter type="plain"/>

    <batchtest todir="${ testresults.dir}">
        <fileset dir="${src.test}">
            <include name="**/*Test*.java"/>
        </fileset>
    </batchtest>

</junit>





On 14/06/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>
> > Presumably you are running <junit> forked? I think you also need to
> make
> > sure that your path and library search path includes the existing env
> > variables.
>
> Mostly likely not. The only "right" solution is to <junit fork="true">.
>
> > > Am I going to be forced to look into a nominated directory and
> preload
> > > anything that matches *.so before invoking a non-forked JVM for the
> unit
> > > tests?
>
> That would be a hack, and even then you'd have to load them in the
> proper dependency order. I had a too-clever colleague use such an
> approach to work around a similar issue in WebStart, but it's very
> brittle, and very hacky.
>
> It's not a matter of using LoadLibraryEx or not, since *nix in general
> does not allow you to alter the library loading path of an existing
> process.
>
> So just fork your tests ;-) --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>

Reply via email to