Re[4]: [JBoss-dev] PHP
we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is provided by a HB SAPI module that interfaces with the Servlet server, the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +--+ | Zend Engine | +--+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +--+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt.| | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +--+ | Authors: Andi Gutmans [EMAIL PROTECTED]| | Zeev Suraski [EMAIL PROTECTED]| +--+ */ HB anybody thought about integrating php (and this way the cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise
Re: Re[4]: [JBoss-dev] PHP
mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is provided by a HB SAPI module that interfaces with the Servlet server, the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +--+ | Zend Engine | +--+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +--+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt.| | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +--+ | Authors: Andi Gutmans [EMAIL PROTECTED]| | Zeev Suraski [EMAIL PROTECTED]| +--+ */ HB anybody thought about integrating php (and this way the cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried
RE: Re[4]: [JBoss-dev] PHP
holger, we totally agree and we are talking about the same thing. I already proposed it to Julien back when we wanted to go PN. The idea is indeed to RUN PHP APPS AS IS in JBoss but with the merit of same VM cache access. That is what it is all about and what is killing the current www.jboss.org machine under apache/php, the fact that PHP is a lot of servlet/jdbc equivalent code done poorly. Let's do a port for now, with EJB representing the tables so that at least we remove the JDBC code (or ODBC or whatever it is PHP uses) and leverage some cache. It will speed www.jboss.org speed by ten. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is HB provided by a SAPI module that interfaces with the Servlet server, HB the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt. | | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can
Re[4]: [JBoss-dev] PHP
zend engine is PHP parser-compiler from zend company : www.zend.com now they are working on a version 2 with more robust object as said on their website. finally they'll have a true OOP language julien mf what is the zend engine? mf marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of julien viet Sent: Thursday, January 09, 2003 6:27 PM To: Holger Baxmann Subject: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt. | | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +- -+ | Authors: Andi Gutmans [EMAIL PROTECTED] | | Zeev Suraski [EMAIL PROTECTED] | +- -+ */ HB anybody thought about integrating php (and this way the HB cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf
Re: Re[4]: [JBoss-dev] PHP
finally they'll have a true OOP language OOP in this case: Other Orphaned Preprocessor ;-) bax julien mf what is the zend engine? mf marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of julien viet Sent: Thursday, January 09, 2003 6:27 PM To: Holger Baxmann Subject: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject to version 2.00 of the Zend license, | | that is bundled with this package in the file LICENSE, and is| | available at through the world-wide-web at | | http://www.zend.com/license/2_00.txt. | | If you did not receive a copy of the Zend license and are unable to | | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +- -+ | Authors: Andi Gutmans [EMAIL PROTECTED] | | Zeev Suraski [EMAIL PROTECTED] | +- -+ */ HB anybody thought about integrating php (and this way the HB cms-whatever-this-is HB thingy) into the the containers? maybe by calling the zend engine natively? HB layer rules ... HB just an idea .. HB bax Von: Bill Burke [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Thu, 9 Jan 2003 15:34:10 -0500 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] PHP IWE. Go Go Julien Viet! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Thursday, January 09, 2003 3:16 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Marc group, Thanks for the details. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. My good friend Google just explained CMS publishing to me, and I think I understand the issue. It is not PHP vs. J2EE, but Post-Nuke vs. a J2EE-based CMS that apparently DNE. Not the best situation... - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 2:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] PHP Bill, Don't worry, I'm not going to blast you for not eating your own dog food. you should. JSP/Servlets/J2EE is better, but PostNuke is a good Content Management System. This statement, in and of itself, is a rationale for using J2EE instead of PHP ;) Could you divulge the precise reason(s) for choosing Post-Nuke? (I can think of many factors that often outweigh technical superiority -- time, money, expedience, IP issues... was it one of these?) the real reason is that the APPLICATION IS THERE. We tried to rewrite the forums (which we did) and it took us for ever due to the publishing framework getting in the way. The problem we have is that PostNuke is a bunch of PHP files with direct DB access in it and we are having scalability nightmares. Our machine used to be 15% utilization max (slashdot was 50%) due TO THE CACHES IN JBOSS. And without it, we have 100 people on the website and the machine is pegged. So the application is there so we use it. We need it NOW. Julien viet, who was writing the forums, is now on JBoss payroll and will be working on JNUKE. A straight port of PHP functionality to JBoss. PHP is ugly and functional, my kind of code but at the end of the day it doesn't scale well at all due to all the crap they do. EJB are good things :) Peace, marcf --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED]
RE: Re[4]: [JBoss-dev] PHP
I've been looking into this as you speak. Seems from reading doco that you can't go Java-PHP-Java which is what we need. Not sure what would happen if PHP called from Java created a JVM. Too bad there isn't a PHP Jython like thing Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, January 09, 2003 7:35 PM To: [EMAIL PROTECTED] Subject: RE: Re[4]: [JBoss-dev] PHP holger, we totally agree and we are talking about the same thing. I already proposed it to Julien back when we wanted to go PN. The idea is indeed to RUN PHP APPS AS IS in JBoss but with the merit of same VM cache access. That is what it is all about and what is killing the current www.jboss.org machine under apache/php, the fact that PHP is a lot of servlet/jdbc equivalent code done poorly. Let's do a port for now, with EJB representing the tables so that at least we remove the JDBC code (or ODBC or whatever it is PHP uses) and leverage some cache. It will speed www.jboss.org speed by ten. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is HB provided by a SAPI module that interfaces with the Servlet server, HB the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject
Re: Re[4]: [JBoss-dev] PHP
I've been looking into this as you speak. Seems from reading doco that you can't go Java-PHP-Java which is what we need. Not sure what would happen if PHP called from Java created a JVM. Too bad there isn't a PHP Jython like thing have a look at the java sapi (server [sic!] application interface) and the servlet.java, there you can call the php engine - zend - out of a servlet container. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, January 09, 2003 7:35 PM To: [EMAIL PROTECTED] Subject: RE: Re[4]: [JBoss-dev] PHP holger, we totally agree and we are talking about the same thing. I already proposed it to Julien back when we wanted to go PN. The idea is indeed to RUN PHP APPS AS IS in JBoss but with the merit of same VM cache access. That is what it is all about and what is killing the current www.jboss.org machine under apache/php, the fact that PHP is a lot of servlet/jdbc equivalent code done poorly. Let's do a port for now, with EJB representing the tables so that at least we remove the JDBC code (or ODBC or whatever it is PHP uses) and leverage some cache. It will speed www.jboss.org speed by ten. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is HB provided by a SAPI module that interfaces with the Servlet server, HB the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project is hosted by apache. Here is the header they use in sourecode : /* +- -+ | Zend Engine | +- -+ | Copyright (c) 1998-2002 Zend Technologies Ltd. (http://www.zend.com) | +- -+ | This source file is subject
RE: Re[4]: [JBoss-dev] PHP
Damn PHP install doesn't even work for the java stuff. Followed directions and can't get it to build. Now I'm hacking Makefiles :( -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 8:03 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP I've been looking into this as you speak. Seems from reading doco that you can't go Java-PHP-Java which is what we need. Not sure what would happen if PHP called from Java created a JVM. Too bad there isn't a PHP Jython like thing have a look at the java sapi (server [sic!] application interface) and the servlet.java, there you can call the php engine - zend - out of a servlet container. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, January 09, 2003 7:35 PM To: [EMAIL PROTECTED] Subject: RE: Re[4]: [JBoss-dev] PHP holger, we totally agree and we are talking about the same thing. I already proposed it to Julien back when we wanted to go PN. The idea is indeed to RUN PHP APPS AS IS in JBoss but with the merit of same VM cache access. That is what it is all about and what is killing the current www.jboss.org machine under apache/php, the fact that PHP is a lot of servlet/jdbc equivalent code done poorly. Let's do a port for now, with EJB representing the tables so that at least we remove the JDBC code (or ODBC or whatever it is PHP uses) and leverage some cache. It will speed www.jboss.org speed by ten. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Holger Baxmann Sent: Thursday, January 09, 2003 7:28 PM To: [EMAIL PROTECTED] Subject: Re: Re[4]: [JBoss-dev] PHP mmmmmm, i am not talking about porting xor integration. i am talking about php beeing a _frontend_ in the depest meaning. unfortunately was this not sufficient for the php people to fullfill the the marketing flyers of their products. so they called the backend, and there is definitely only one possible, directly via libraries. what stands against a jboss-faking-the-backend-library? we will provide the smooth migration not only to jboss, but to the bunches of running businesses in php too. if we have html, soap, corba, rmi, etc. etc. 'frontends' then php seems not a problem for me. let's do both bax Von: julien viet [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 01:14:23 +0100 An: Holger Baxmann [EMAIL PROTECTED] Betreff: Re[4]: [JBoss-dev] PHP we already tried to investigate that way a couple of month ago. but servlet and PHP are not in the same space. Therefore no tight interraction is possible with jboss, serialization issues are a consequence. julien HB just found it: HB XLVIII. Java HB There are two possible ways to bridge PHP and Java: you can either integrate HB PHP into a Java Servlet environment, which is the more stable and efficient HB solution, or integrate Java support into PHP. The former is HB provided by a SAPI module that interfaces with the Servlet server, HB the latter by the Java HB extension. HB at: http://php.benscom.com/manual/kr/ref.java.php HB bax Von: Holger Baxmann [EMAIL PROTECTED] Antworten an: [EMAIL PROTECTED] Datum: Fri, 10 Jan 2003 00:57:31 +0100 An: [EMAIL PROTECTED] Betreff: Re: Re[2]: [JBoss-dev] PHP I thought about it, but that wouldn't solve the case. Direct DB would still be used and slowness would still be there, PHP db functions would be mapped to JDBC. The problem is not PHP, it's the way PHP guys code. i know, deeply: i know. my last paid job was for a company with around 80.000 php source code lines in a collaboration app. one option to go not blasted away was porting this to j2. the company has had no further life because of not taking the option :) imho, there are not too many functions that the guys are calling, around some hundred. if we are able to fake - licensingwise the functionality of - the zend engine via a filter, it bites me to use 'interceptor' - before the engine is called, we should have a smooth migration to jboss through parsing the php code to - ok, ok - xml/xsd, don't we? the particular sql dialect is not really more complicated than the uglyiest php script. the db access should not be the real problem - most of them use mysql anyway. a) this is no database b) jboss should be able to behave like a non-transactional thing like this bax Anyway that would be a great project and could attract many developpers onto J2EE platform. There do not exists a PHP specification. Such a project would consist in retro engineering there compiler. In fact I don't know anything about zend and their licence, though project
