193 lines (140 with data), 7.1 kB
php-java-bridge NEWS -- history of user-visible changes.
Please send bug reports, questions and suggestions to
<php-java-bridge-users@lists.sourceforge.net>.
Version 3.0.3:
* Communication via named pipes: When the backend is running inside a
Unix servlet engine or application server, the bridge uses named pipes
instead of TCP sockets. This communication channel is 1.5 times faster
than unix domain sockets and 2 times faster than TCP sockets. TCP
sockets are still used on systems which do not support standard Unix
named pipes (Windows).
* Because of the above change the bridge now works with the "Sun Java
System Application Server Platform Edition 8" on Unix.
* TCP sockets only listen on the local (127.0.0.1) interface unless
the system property "php.java.bridge.promiscuous" is set to true.
* The apache jsf "myfaces" implementation, which caused problems with
various application servers or servlet engines, has been replaced by
JSF 1.1.01.
Version 3.0.2:
* Backward compatibility with 2.0.8: The java.servlet can now have
three values:
On : Selects the default servlet context, which is
/JavaBridge/JavaBridge.php
Off : Switches off the HTTP tunnel
User: Selects the "current" servlet context. A request:
http://foo.com/context1/test.php connects test.php to the
backend: http://<java.hosts[0]>/context1/test.php.
Example:
[java]
java.hosts=127.0.0.1:8080
java.servlet=User
Request:
http://foo.com/contextA/order.php
Then order.php sends a PUT request to the backend:
http://127.0.0.1:8080/contextA/order.php
* The servlet mapping for PhpJavaServlet has been
removed. java.servlet=User or
java.servlet=/JavaBridge/PhpJavaServlet.php can be used instead.
* When the java VM was started as a child of apache (OPTION#3) and
apache sent out a kill signal to all childs in its process group, the
guard process (which observes the VM) could be killed. After that one
had to kill the java child manually. Since version 3.0.2 the guard
detaches from the apache process group, too
* The PHP5/PHP6 array access and iterator interface should be much
faster now. Especially the array access was incredibly inefficient
as it allocated a new instance of PhpMap for each access.
Version 3.0.1:
* JSR223 API: It is now possible to run php scripts from java. Scripts
are invoked using a CPS style, a CGI binary is started if necessary
(if Apache/IIS are not running).
Example:
PhpScriptEngine engine = new PhpScriptEngine();
engine.put("key", "testVal");
// Hold the script from 127.0.0.1:80 (Apache pool) hostage ...
engine.eval(new URLReader(new URL("http://127.0.0.1:80/HelloWorld.php")));
// ... call the php procedure HelloWorld.php::java_get_server_name() ...
System.out.println(((Invocable)engine).call("java_get_server_name", new Object[]{}));
// ... and release the script.
engine.release();
See the configure option --enable-script.
* Java Server Faces: It is possible to embed php scripts into
frameworks. Requires php-faces.jar (see configure option
--enable-faces=<myFaces.jar>). The implementation works with the RI
and Apache myfaces implementation (included in the unsupported
folder). See examples/java-server-faces for details.
* PHP 4 is no longer supported (the bridge still works with php4).
* The bridge no longer coerces return values. If you want to
cast a java string into a php string, use the cast operator, e.g:
$string = new java("java.lang.String", "{HelloWorld}");
$substring = $string->substring(1);
$substring = $substring(0, $substring->length()-1);
echo "Result: $substring"; // implicit cast
echo (string)$substring; // explicit cast
* When running in a servlet engine or application server, the bridge now
supports a multi-user environment. Example tomcat setup which contains:
webapps/userA/...
WEB-INF/lib/{JavaBridge.jar,php-servlet.jar}
WEB-INF/cgi/{php.ini,php-cgi-i386-linux.sh,java.so}
{sessionSharing.php,sessionSharing.jsp}
webapps/userB/...
WEB-INF/lib/{JavaBridge.jar,php-servlet.jar}
WEB-INF/cgi/{php.ini,php-cgi-i386-linux.sh,java.so}
{sessionSharing.php,sessionSharing.jsp}
Browser request for:
http://myhost.com/userA/sessionSharing.php
http://myhost.com/userA/sessionSharing.jsp
Creates cookie with a PATH value: path=/userA
Same browser request for:
http://myhost.com/userB/sessionSharing.php
http://myhost.com/userB/sessionSharing.jsp
Creates cookie with a PATH value: path=/userB
* An administrator may setup a FastCGI PHP server or Apache/IIS as a
frontend so that users don't have to copy their own php binaries into
their WEB-INF/cgi/ folder.
1) Example: Apache/IIS/mod_jk connector:
internet
clients <-> :80---> Apache/IIS ---> J2EE AS
| | / / | |
| mod_jk <-- jsp/servlet req./ / | |
| / jsp |
---- php / |
---- php <-- P-J-B PROTOCOL --/ servlet
... ...
J2EE port not visible to internet clients. Apache/IIS document root
not used.
2) Example: a shared document directory:
:80---> Apache/IIS
/ |
/ php req. ---- php
/ ---- php <--|
... |
internet |
clients |
\ |P-J-B
\jsp/servlet req. |PROTOCOL
\ |
|
|--> :8080--> J2EE AS |
| | |
| ---- jsp |
| ---- servlet |
| ... |
-------------------------------|
Apache/IIS and J2EE ports are accessible from the
internet. Apache/IIS and the J2EE AS share the same document root.
#2 is the recommended setup. Framework requests (e.g.: hello.jsf)
go to port 8080, initial requests to :80 can be forwarded to the
framework using the following php code:
<?php
// hello backing implementation
function jsfValidateEntry(...) {...}
...
// check if we're called from the JSF framework, redirect to
// self.jsf otherwise.
function redirect() {
$target=dirname($_SERVER['PHP_SELF']);
$name=basename($_SERVER['PHP_SELF'], ".php");
header ("Location: http://$_SERVER[HTTP_HOST]:8080$target/$name.jsf");
}
java_context()->call(java_closure()) || redirect();
?>