php-java-bridge-users Mailing List for PHP/Java Bridge

Hi,

older versions used to support unix-domain socket communication on certain
operating systems. Since version 5.4.4.2 this path is broken:

>From PROTOCOL.TXT:
*" It is possible to send the header even though the connection has
already been established. The bridge will ignore the header if the
second byte is not 0xFF."

*
However, 0xFF seems be uses to implement a short path for the
Servlet/JEE/Tomcat container now (btw: the buf[1] should really be buf[c+1],
but that doesn't matter, as c is guaranteed to be 0 at the beginning of the
communication). In order to support unix domain socket communicationn again,
we need to add a method "parseHeader()" to the IDocHandler interface, so
that we can move the code implementation below to the servlet context and
use the old code implementation from the cvs in the standalone context. Oh,
and PROTOCOL.TXT should document this properly.

  235 		case 0177: if(in_dquote) {APPEND(ch); break;}
  236 		    // the header used to be binary encoded
  238 		    bridge.out.write(0); bridge.out.flush(); // dummy write:
avoid ack delay
  239 		    int len =(0xFF&buf[c+2]) | (0xFF00&(buf[c+3]<<8));
  244 		    byte shortPathHeader = (byte) (0xFF&(buf[1]));
  245 		    if(shortPathHeader != (byte) 0xFF)  // short path: no
previous PUT request

Hi Massimo,

> I have to build a standalone, multiplatform PHP application that needs
> to use a number of java classes

Is it a standalone web- or desktop application? Since you mention swing, I
assume you want to write a desktop app.

I would start by writing the Java GUI skeleton and then add PHP
functionality to it, please see
http://php-java-bridge.sourceforge.net/pjb/standalone.php for an example.

*I* would write the entire application in java. PHP makes sense for
short-lived scripts, but I wouldn't use it to drive the entire desktop
application. -- I think PHP 5.3's new reference counter can reclaim certain
cycles, but I wouldn't trust it.

If you want to use PHP as a plugin only, use the JSR 223 API.


> PHP-equipped Jetty (http://jetty.mortbay.org/jetty/) on localhost

Why do you need jetty for a desktop application?


Regards,
Jost Boekemeier

Hi Jost & all,
 
I have to build a standalone, multiplatform PHP application that needs
to use a number of java classes in both the "business" logic (e.g. the
cryptography package from Bouncy Castle) and the graphical user
interface (3rd party UI components).
 
While being proficient in PHP the same cannot be said for Java, so I've
being researching a good "hybrid" solution to get the job done and am
currently focusing on a Java Swing front-end calling a PHP-equipped
Jetty (http://jetty.mortbay.org/jetty/) on localhost.
 
Specifically, I'd like to visually create the GUI with the NetBeans IDE,
register the appropriate Event Listeners and implement all non-trivial
(or forcibly Java) event-handling code in PHP, and I am struggling to
understand strengths and weaknesses of the available options ...
following is the list of alternatives I've come up with until now:
 
1) Just make an HTTP request from the event method to a PHP script on
the Jetty back-end, where PHP can interact via PJB with any needed Java
classes or simply make use of all its built-in functionality to generate
a response. This solution implies I have to manage all response data and
interface navigation in Java; also, there won't be any continuation
passing between the Swing front-end and the PHP back-end, resulting in a
somewhat less efficient interaction;
 
2) Write Java code using JSR 223 and PJB to call PHP classes/methods on
the Jetty back-end. Still need to write Java code, nonetheless it looks
like a better solution performance-wise: problem is, to date I didn't
manage to call PHP user functions/classes from such an application - I
can run the phpversion() sample provided, but that's it. Probably my
fault, anyway I'd welcome a more complex example;
 
3) Expand the example in
http://php-java-bridge.sourceforge.net/pjb/standalone.php so the Swing
application makes HTTP calls to Jetty's PHP scripts. Instead of
returning a response like in 1), the PHP code interacts with
appropriately exposed application methods. I believe one could, to a
point, even control the interface navigation from PHP in this way.
 
Are there other alternatives to consider (I may be missing even the
simplest, most elegant solution)?
 
Regards,
Massimo