Re: [PHP4BETA] Help Please:... undefined symbol: JNI_CreateJavaVM

Hi, Sam i decided to go ahead and build php into a servlet. However, I've run into a couple of layers of trouble I hope you can help me out of. Firstly, when compiling in sapi/servlet I get the following error: net/php/servlet.java:75: Method addHeader(java.lang.String, java.lang.String) not found in interface javax.servlet.http.HttpServletResponse. response.addHeader(data.substring(0,colon), ^ net/php/servlet.java:121: Incompatible type for constructor. Can't convert java.io.IOException to java.lang.String. throw new ServletException(e); ^ ... which I made go away with the following changes to servlet.java: 75c75 < response.addHeader(data.substring(0,colon), --- > response.setHeader(data.substring(0,colon), 121c121 < throw new ServletException(e); --- > throw new ServletException(""); After making these changes, it compiled and installed without a hitch. Notice I said "made go away" and not "fixed" before, since the next problem arose when attempting to load a simple phpfile with <?php phpinfo(); ?> in it. Here's the apache error_log: Fatal System Error: Raise at top of Exception Stack SIGABRT 6* abort (generated by abort(3) routine, also SIGIOT) si_signo [6]: SIGABRT 6* abort (generated by abort(3) routine, also SIGIOT) si_errno [0]: Success si_code [0]: SI_USER [pid: 0, uid: 0] stackpointer=0xbedfe14c Full thread dump Classic VM (Linux_JDK_1.2.2_RC4, native threads): "Thread-409" (TID:0x40e7e9e8, sys_thread_t:0x83398f0, state:R, native ID:0x67407) prio=5 at net.php.servlet.send(Native Method) at net.php.servlet.service(servlet.java, Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java, Compiled Code) at org.apache.jserv.JServConnection.processRequest(JServConnection.java, Compiled Code) at org.apache.jserv.JServConnection.run(JServConnection.java, Compiled Code) at java.lang.Thread.run(Thread.java, Compiled Code) "Thread-1" (TID:0x40e76b58, sys_thread_t:0x850d9c8, state:CW, native ID:0x1406) prio=5 at java.lang.Thread.sleep(Native Method) at org.apache.jserv.JServServletManager.run(JServServletManager.java, Compiled Code) at java.lang.Thread.run(Thread.java, Compiled Code) "Thread-0" (TID:0x40e71900, sys_thread_t:0x83e71a8, state:CW, native ID:0x1005) prio=1 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java, Compiled Code) at org.apache.java.util.SimpleQueue.waitObject(SimpleQueue.java, Compiled Code) at org.apache.java.io.LogWriter$Agent.run(LogWriter.java, Compiled Code) "Finalizer" (TID:0x40e69320, sys_thread_t:0x80d0a80, state:CW, native ID:0xc04) prio=8 at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java, Compiled Code) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174) "Reference Handler" (TID:0x40e693b0, sys_thread_t:0x80ca658, state:CW, native ID:0x803) prio=10 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java, Compiled Code) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114) "SIGQUIT handler" (TID:0x40e693e0, sys_thread_t:0x80cff30, state:R, native ID:0x402) prio=5 "main" (TID:0x40e691e0, sys_thread_t:0x80533b0, state:R, native ID:0x400) prio=5 at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java, Compiled Code) at java.net.ServerSocket.implAccept(ServerSocket.java, Compiled Code) at java.net.ServerSocket.accept(ServerSocket.java, Compiled Code) at org.apache.java.net.AuthenticatedServerSocket.accept(AuthenticatedServerSocket.java, Compiled Code) at org.apache.jserv.JServ.main(JServ.java, Compiled Code) Monitor Cache Dump: java.lang.ref.ReferenceQueue$Lock@40E69338/40E9ED78: <unowned> Waiting to be notified: "Finalizer" (0x80d0a80) java.lang.ref.Reference$Lock@40E693C0/40E9E8A8: <unowned> Waiting to be notified: "Reference Handler" (0x80ca658) org.apache.java.util.SimpleQueue@40E78690/40EF08E0: <unowned> Waiting to be notified: "Thread-0" (0x83e71a8) java.net.PlainSocketImpl@40E701C0/40EF4F58: owner "main" (0x80533b0) 1 entry Registered Monitor Dump: PCMap lock: <unowned> utf8 hash table: <unowned> JNI pinning lock: <unowned> JNI global reference lock: <unowned> BinClass lock: <unowned> Class linking lock: <unowned> System class loader lock: <unowned> Code rewrite lock: <unowned> Heap lock: <unowned> Monitor cache lock: owner "Thread-409" (0x83398f0) 1 entry Thread queue lock: owner "Thread-409" (0x83398f0) 1 entry Monitor registry: owner "Thread-409" (0x83398f0) 1 entry [Thu Feb 24 18:19:02 2000] [error] [client 207.153.206.36] Premature end of script headers: /servlets/net.php.servlet This seems to refer to the usage of the send method on line 113 of servlet.java, but unfortunately I don't know enough about java to track it down further. BTW, I'm using Apache JServ and JSDK2.0. Any thoughts? I gotta hunch the second problem is related to my "fix" of the first one. Am I just delusional? thanks in advance Jason rubys@us.ibm.com wrote: > > > yeah, just for kicks I set LD_LIBRARY_PATH and reinstalled. Same effect. I > > wish I knew my way around C/C++ better, but it seems to me that it's not > > including jni.h properly. Then again, if I'm the only person with this problem, > > my machine is probably on smack... > > jni.h is read at compile time. Your problem is at execution time. > > Starting a JVM via JNI seems to be a very delicate and finicky thing. You > are not the only one who has had trouble doing this. I'm contemplating > adding a section to the top of the ext/java readme indicating that this > support is only for masocists with high volume sites withouth much usage of > Java. Everyone else who is interested in using Java should use > sapi/servlet. > > sapi/servlet is essentially a front end to ext/java. Two basic > differences: > > 1) it uses your existing JVM instead of attempting to create a new one > 2) php access to the web server (requests, responses, etc) are routed > through Java. > > The warnings in the readme reflect a time when ext/java wasn't as smart as > it is today (for example, it couldn't handle overloading well). I'm > tracking down my last bug in handling sessions, at which time I plan to > remove these warnings. > > - Sam Ruby