java call out to make a JNI system call.

I am trying to implement java-call-out to make a JNI system call. Inside java call out I am loading some

native libraries

System.load("*****)

But apigee is throwing below error

fault-string: no *** library in java.library.path

I understand that I have export or source LD_LIBRARY_PATH (apigee is on linux host).

If my understanding is correct, How can I source ld_library_path for java call out?

0 3 239
3 REPLIES 3

You can't.

You can't do that. You cannot load native libraries.

JNI is restricted by policy in Apigee Edge.

If you want to write an elaborate Java app that loads native libraries, you will need to use a Java hosting environment. Google App Engine works, or you can try something else. You can use Apigee Edge to provide the API Management layer on top of that more elaborate Java app.

Thanks for the quick reply, appreciate that. @Dino-at-Google

But can you elaborate on this

(you will need to use a Java hosting environment. Google App Engine works, or you can try something else. You can use Apigee Edge to provide the API Management layer on top of that more elaborate Java app.)

you are saying that I cannot load (.so) libraries using (System.load(****)) which are specific to

my organization (apigee-on-prem FYI) in java-call-out code. Is my understanding correct ?

Thanks

kalyan inturi

By default, yes. If you are using Apigee Edge on-prem, you can relax the security policies of course, to allow you to load .so modules and perform JNI. You have the capability via CWC to change the security policies that apply to Java callouts.

But, that scenario has not been tested by Apigee, and I believe it would not be supported. The reason is: those JNI modules can do lots of things that might affect the consumption of resources like memory, file descriptors, cpu, and so on, which would affect the behavior of the MP. If later, you were to run into some performance or behavior problem with an MP running Java callouts that used JNI, I suppose Apigee Support would first ask you to remove those parts and only after you did that, would they be ready to help you diagnose the problem.

A better approach would be to just host the Java logic (with JNI and etc) in a system designed to host Java apps.