On Thu, Jul 11, 2019 at 8:42 PM Rainer Jung <rainer.j...@kippdata.de> wrote:

> Hi Rémy,
>
> Am 11.07.2019 um 18:35 schrieb Rémy Maucherat:
> > On Thu, Jul 11, 2019 at 4:36 PM Rainer Jung <rainer.j...@kippdata.de
> > <mailto:rainer.j...@kippdata.de>> wrote:
> >
> >     Probably not very helup, but to make sure, the GetEnv is failing, I
> >     would add a little code to native/src/jnilib.c in JNI_OnLoad() that
> >     creates an observable side effect while executing int he function.
> E.g.
> >     on Unix/Linux you could add something like
> >
> >     #include <stdio.h>
> >
> >     ...
> >
> >     FILE *fd = fopen("/tmp/mytrace", "w");
> >     int fputs("At step 1", fd);
> >     int fflush(fd);
> >     ...
> >     int fputs("At step 2", fd);
> >     int fflush(fd);
> >     ...
> >     int fputs("At step N", fd);
> >     int fflush(fd);
> >     int fclose(fd);
> >
> >     Sure poor man's tacing, but it will show, how for you get through
> >     JNI_OnLoad() before it is returning.
> >
> >     Sorry for not being more helpful,
> >
> >
> > Good idea. So it's failing on:
> > TCN_LOAD_CLASS(env, jFinfo_class, TCN_FINFO_CLASS, JNI_ERR);
> > And I need to define this in the JNI configuration, much like it's done
> > for Java reflection and dynamic class loading. Only difference I haven't
> > really been using it yet. The classes are traced but the configure tool
> > which converts the trace into the config does not work properly [yet].
>
> When one looks up the macros in native/include/tcn.h, this boils down to
> the following returning null:
>
> (*env)->FindClass(env, "org/apache/tomcat/jni/FileInfo")
>
> So our own FileInfo class can not be found. FindClass docs indicate its
> searched in the CLASSPATH although I'm not sure whether its really the
> classpath or some search paths of a class loader hierarchy.
>
> You might want to add the JVM commandline flag "-verbose:class" for any
> easy way to track class loading.
>
> I didn't really grok what you meant with "define in JNI configuration".
> For normal JVMs the code just works, so what might be special for Graal
> that org.apache.tomcat.jni.FileInfo can't be found?
>

A Graal native image is indeed not a normal JVM and does not support any
kind of dynamic class loading, it has to be declared first in these
configuration files.
So I am adding this to the jni one:
{ "name":"org.apache.tomcat.jni.FileInfo" },
{ "name":"org.apache.tomcat.jni.Sockaddr" },
{ "name":"org.apache.tomcat.jni.FileInfo" },
{ "name":"java.lang.String", "methods" :
[{"name":"<init>","parameterTypes":["byte[]"]},{"name":"getBytes","parameterTypes":[]}]
}
And loading now works.
Jul 11, 2019 9:39:28 PM org.apache.catalina.core.AprLifecycleListener
lifecycleEvent
INFO: Loaded APR based Apache Tomcat Native library [1.2.23] using APR
version [1.6.5].
Jul 11, 2019 9:39:28 PM org.apache.catalina.core.AprLifecycleListener
lifecycleEvent
INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters
[false], random [true].
Jul 11, 2019 9:39:28 PM org.apache.catalina.core.AprLifecycleListener
lifecycleEvent
INFO: APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
Jul 11, 2019 9:39:28 PM org.apache.catalina.core.AprLifecycleListener
initializeSSL
INFO: OpenSSL successfully initialized [OpenSSL 1.1.1c FIPS  28 May 2019]

However when trying to actually connect I got:
Segmentation fault (core dumped)

Oops.

Rémy


> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Reply via email to