Menu
▾
▴
php-java-bridge-users
|
From: <php...@li...> - 2007-05-23 16:49:22
|
Hi. Since this is my first posting at this mailing list, I'd like to
thank you for providing and maintaing the PHP-Java-Bridge.
I'm using PHP-Java-Bridge version 4.0.1 (PHP 5.x & 5.2.1, Sun Java
1.5.x, Tomcat 5.5.x, Ubuntu 6.10 & 7.04).
There are Tomcat webapps which are almost identical -- one Java
properties file differs, running under the same instance of Tomcat.
Now, a PHP file in webapp1instantiates a new Java class of mine, which
in turn calls a static Java class of mine, which again reads that
properties file:
ResourceBundle.getBundle("myProps").getString(key);
myProps is WEB-INF/classes/myProps.properties.
What happens is, webapp1 will access the property file of webapp2!
If webapp2 is undeployed, webapp1 will use its own property file again.
I've confirmed this behavior on a clean installation/copy of Tomcat (the
same effects, but here, webapp2 will use webapp1's properties file).
On another computer (Ubuntu 7.04, PHP 5.2.1) (the one where the problem
occurs is Ubuntu 6.10, PHP 5.x) the problem does *not* occur.
The Java classes involved (but JavaBridge.jar, which is in the
$CLASSPATH) are all in WEB-INF/classes, only.
When I run the same Java classes from a JSP, the right properties file
will be accessed.
Any ideas?
Thanks
Robert
|
|
From: <php...@li...> - 2007-05-24 10:27:30
|
The problem has been solved by upgrading Ubuntu from 6.10 to 7.04, and
PHP from 5.1.6 to 5.2.1.
Thanks
php...@li... wrote:
> Hi. Since this is my first posting at this mailing list, I'd like to
> thank you for providing and maintaing the PHP-Java-Bridge.
>
> I'm using PHP-Java-Bridge version 4.0.1 (PHP 5.x & 5.2.1, Sun Java
> 1.5.x, Tomcat 5.5.x, Ubuntu 6.10 & 7.04).
>
> There are Tomcat webapps which are almost identical -- one Java
> properties file differs, running under the same instance of Tomcat.
>
> Now, a PHP file in webapp1instantiates a new Java class of mine, which
> in turn calls a static Java class of mine, which again reads that
> properties file:
> ResourceBundle.getBundle("myProps").getString(key);
> myProps is WEB-INF/classes/myProps.properties.
>
> What happens is, webapp1 will access the property file of webapp2!
>
> If webapp2 is undeployed, webapp1 will use its own property file again.
> I've confirmed this behavior on a clean installation/copy of Tomcat (the
> same effects, but here, webapp2 will use webapp1's properties file).
> On another computer (Ubuntu 7.04, PHP 5.2.1) (the one where the problem
> occurs is Ubuntu 6.10, PHP 5.x) the problem does *not* occur.
> The Java classes involved (but JavaBridge.jar, which is in the
> $CLASSPATH) are all in WEB-INF/classes, only.
>
> When I run the same Java classes from a JSP, the right properties file
> will be accessed.
>
> Any ideas?
>
> Thanks
> Robert
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> php-java-bridge-users mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users
>
>
|
|
From: <php...@li...> - 2007-05-24 11:25:09
|
Hi,
> The problem has been solved by upgrading Ubuntu from
> 6.10 to 7.04, and
> PHP from 5.1.6 to 5.2.1.
not so fast, please. :)
First of all, it seems that you have copied the
JavaBridge.jar and php-script.jar into the tomcat
shared lib folder. This means that the same JavaBridge
instance is responsible for all your web applications.
In such a setup it is certainly possible to access
classes from a sibling context. However, the bridge
passes the current web context via the protocol
request header.
Can you please open a problem report and set the log
level to 6:
export
JAVA_OPTS="-Dphp.java.bridge.default_log_level=6"
/opt/jakarta-tomcat*/bin/catalina.sh run
And attach the log at the end of the ticket?
We will look at this issue asap.
Regards,
Jost Boekemeier
Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail
|
|
From: <php...@li...> - 2007-05-29 10:06:52
|
Hi,
first of all thank you very much for the bug report.
We could reproduce the problem that, when the PHP/Java
Bridge is installed in the shared directory, as
described in our FAQ, all classes are loaded via the
same webapp classloader.
We currently don't have a workaround for this tomcat
problem.
However, this isn't a bug in the PHP/Java Bridge code,
so we won't fix this problem, even though it is
serious.
> What happens is, webapp1 will access the property
> file of webapp2!
Yes. When the JavaBridge.jar and php-servlet.jar are
loaded from the shared web folder, tomcat loads all
classes from the same web classloader. This is almost
certainly a tomcat bug.
> occurs is Ubuntu 6.10, PHP 5.x) the problem does
> *not* occur.
It should occur in all Tomcat versions < 6.
> When I run the same Java classes from a JSP, the
> right properties file
> will be accessed.
JSP is different. It compiles Java source files to
Java byte code and then invokes the byte code from a
separate classloader. The PHP/Java Bridge could do the
same to work around the above problem.
In the meantime please do not copy the JavaBridge.jar
and php-servlet.jar into the shared tomcat directory.
Regards,
Jost Boekemeier
Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail
|
|
From: <php...@li...> - 2007-05-29 10:09:04
|
Hi,
first of all thank you very much for the bug report.
We could reproduce the problem that, when the PHP/Java
Bridge is installed in the shared directory, as
described in our FAQ, all classes are loaded via the
same webapp classloader.
We currently don't have a workaround for this tomcat
problem.
However, this isn't a bug in the PHP/Java Bridge code,
so we won't fix this problem, even though it is
serious.
> What happens is, webapp1 will access the property
> file of webapp2!
Yes. When the JavaBridge.jar and php-servlet.jar are
loaded from the shared web folder, tomcat loads all
classes from the same web classloader. This is almost
certainly a tomcat bug.
> occurs is Ubuntu 6.10, PHP 5.x) the problem does
> *not* occur.
It should occur in all Tomcat versions < 6.
> When I run the same Java classes from a JSP, the
> right properties file
> will be accessed.
JSP is different. It compiles Java source files to
Java byte code and then invokes the byte code from a
separate classloader. The PHP/Java Bridge could do the
same to work around the above problem.
In the meantime please do not copy the JavaBridge.jar
and php-servlet.jar into the shared tomcat directory.
Regards,
Jost Boekemeier
__________________________________ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever
|
|
From: <php...@li...> - 2007-05-29 20:44:48
|
Jost, Thank you very much for investigating into this. Thanks, sincerely, for providing and maintaining the PHP-Java-Bridge. I'm just an ordinary user who's, at times, like now, doing overwork to get his tasks done, and it's hard for me to get into details that are not complementary to my actual tasks. I'd like to apologize for that. Anyways, this: > It should occur in all Tomcat versions < 6. probably ain't exactly true - as I'm still using Tomcat 5.5, and upgrading to Ubuntu 7.04 and PHP 5.2 resolved the problems for now. However, I understand the JavaBridge JARs shouldn't be placed into folders shared by multiple Java or Tomcat applications per default. PHP-Java-Bridge is an amazing piece of software, and I'm really thankful you're providing it. Thanks again, high regards, and best of luck Robert php...@li... wrote: > Hi, > > first of all thank you very much for the bug report. > > We could reproduce the problem that, when the PHP/Java > Bridge is installed in the shared directory, as > described in our FAQ, all classes are loaded via the > same webapp classloader. > > We currently don't have a workaround for this tomcat > problem. > > However, this isn't a bug in the PHP/Java Bridge code, > so we won't fix this problem, even though it is > serious. > > > >> What happens is, webapp1 will access the property >> file of webapp2! >> > > Yes. When the JavaBridge.jar and php-servlet.jar are > loaded from the shared web folder, tomcat loads all > classes from the same web classloader. This is almost > certainly a tomcat bug. > > >> occurs is Ubuntu 6.10, PHP 5.x) the problem does >> *not* occur. >> > > It should occur in all Tomcat versions < 6. > > > >> When I run the same Java classes from a JSP, the >> right properties file >> will be accessed. >> > > JSP is different. It compiles Java source files to > Java byte code and then invokes the byte code from a > separate classloader. The PHP/Java Bridge could do the > same to work around the above problem. > > In the meantime please do not copy the JavaBridge.jar > and php-servlet.jar into the shared tomcat directory. > > > Regards, > Jost Boekemeier > > > > __________________________________ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > php-java-bridge-users mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users > > |
|
From: <php...@li...> - 2007-05-30 12:11:50
|
Hi, I have created a ticket for this: => http://sourceforge.net/tracker/index.php?func=detail&aid=1727393&group_id=117793&atid=679233 > Anyways, this: > > It should occur in all Tomcat versions < 6. > probably ain't exactly true - as I'm still using > Tomcat 5.5, and > upgrading to Ubuntu 7.04 and PHP 5.2 resolved the > problems for now. You probably use an old version of the bridge. It is broken in all PHP/Java Bridge versions >= 4.0.1. The bridge versions > 4.0.1 capture the thread context class loader and use it for all shared web contexts (see Util.getContextClassLoader()). Furthermore the bridge doesn't pass the current class loader to the ContextRunners anymore. I have created a fix for this and will attach a SharedPhpJavaBridge.jar at the end of the above ticket. We will merge the SharedPhpJavaBridge.jar with the ordinary JavaBridge.jar after 4.0.8 is released. Regards, Jost Boekemeier Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail |
|
From: <php...@li...> - 2007-06-13 17:17:20
|
Hi, PHP/Java Bridge version 4.1.0 fixes this problem. Please use the following download link: http://sourceforge.net/project/downloading.php?group_id=117793&use_mirror=osdn&filename=php-java-bridge_4.1.0_j2ee.zip&15111070 Since version 4.1.0 the DynamicJavaBridgeClassLoader is optional. When running in a shared web environment, JavaBridge.jar and php-servlet.jar are loaded from the global classpath, the PhpJavaServlet sets the currentThreadContextClassLoader (wrapped by a URLClassLoader, used to load libraries from ~/lib/)into the ContextFactory and the ContextRunners retrieve and use the appropriate ClassLoader. The DynamicJavaBridgeClassLoader is enabled only when the procedure java_require() is called. The bridge allocates a new instance of the DynamicJavaBridgeClassLoader (with the current loader as a delegate) and sets it into the PhpJavaBridgeClassLoader. After the request is done, the DynamicJavaBridgeClassLoader is thrown away. This is necessary because the VM keeps a native cache which is associated the instance of the DynamicJavaBridgeClassLoader. -- Some Java VM's (IBM) even crash, if we do dirty tricks to recycle the instance for new requests (see documentation note in DynamicClassLoader#copyInto). Furthermore the ContextFactory's have been cleaned up. Both, the pure PHP- as well as the C implementation now pass the current context ID via a protocol header field, so that the ContextFactory can temporarily set the correct JavaBridge instance for the current connection (see option java.persistent_connections). This means that most of the old "recycle" logic is now obsolete and has been removed (it may be possible to keep the old cruft, but it is ugly and very hard to understand). Because of the above change, old php_java.dll or java.so files < 4.1.0 will likely crash. For version 4.1.1 I will add a compatibility option which simply disables java.persistent_connections when the back end detects an old protocol header. Until then please use the pure PHP implementation ("Java.inc") instead. Regards, Jost Boekemeier ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de |
|
From: <php...@li...> - 2007-06-13 17:43:42
|
The 4.1.0 ZIP is much, much smaller than all the other versions, and the JavaBridge.war contains almost no data. Is something amiss? > -----Original Message----- > From: php...@li...=20 > [mailto:php...@li...]=20 > On Behalf Of php...@li... > Sent: Wednesday, June 13, 2007 1:16 PM > To: php...@li... > Subject: [Php-java-bridge-users] FYI: PHP/Java Bridge 4.1.0=20 > (test) available (was: Re: Isolation of WebApps under Tomcat) >=20 > Hi, >=20 > PHP/Java Bridge version 4.1.0 fixes this problem. >=20 > Please use the following download link: >=20 > http://sourceforge.net/project/downloading.php?group_id=3D117793 > &use_mirror=3Dosdn&filename=3Dphp-java-bridge_4.1.0_j2ee.zip&15111070 >=20 > Since version 4.1.0 the DynamicJavaBridgeClassLoader > is optional. When running in a shared web environment, > JavaBridge.jar and php-servlet.jar are loaded from the > global classpath, the PhpJavaServlet sets the > currentThreadContextClassLoader (wrapped by a > URLClassLoader, used to load libraries from > ~/lib/)into the ContextFactory and the ContextRunners > retrieve and use the appropriate ClassLoader. >=20 > The DynamicJavaBridgeClassLoader is enabled only when > the procedure java_require() is called. The bridge > allocates a new instance of the > DynamicJavaBridgeClassLoader (with the current loader > as a delegate) and sets it into the > PhpJavaBridgeClassLoader. After the request is done, > the DynamicJavaBridgeClassLoader is thrown away. This > is necessary because the VM keeps a native cache which > is associated the instance of the > DynamicJavaBridgeClassLoader. -- Some Java VM's (IBM) > even crash, if we do dirty tricks to recycle the > instance for new requests (see documentation note in > DynamicClassLoader#copyInto). >=20 > Furthermore the ContextFactory's have been cleaned up. > Both, the pure PHP- as well as the C implementation > now pass the current context ID via a protocol header > field, so that the ContextFactory can temporarily set > the correct JavaBridge instance for the current > connection (see option java.persistent_connections). > This means that most of the old "recycle" logic is now > obsolete and has been removed (it may be possible to > keep the old cruft, but it is ugly and very hard to > understand). >=20 > Because of the above change, old php_java.dll or > java.so files < 4.1.0 will likely crash. For version > 4.1.1 I will add a compatibility option which simply > disables java.persistent_connections when the back end > detects an old protocol header. Until then please use > the pure PHP implementation ("Java.inc") instead. >=20 >=20 > Regards, > Jost Boekemeier >=20 >=20 >=20 > =09 > ___________________________________________________________=20 > Telefonate ohne weitere Kosten vom PC zum PC:=20 > http://messenger.yahoo.de >=20 > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > php-java-bridge-users mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users >=20 >=20 |
|
From: <php...@li...> - 2007-06-14 18:28:15
|
Thanks very much Jost. Your commitment is highly appreciated. Robert php...@li... wrote: > Hi, > > PHP/Java Bridge version 4.1.0 fixes this problem. > > Please use the following download link: > > http://sourceforge.net/project/downloading.php?group_id=117793&use_mirror=osdn&filename=php-java-bridge_4.1.0_j2ee.zip&15111070 > > Since version 4.1.0 the DynamicJavaBridgeClassLoader > is optional. When running in a shared web environment, > JavaBridge.jar and php-servlet.jar are loaded from the > global classpath, the PhpJavaServlet sets the > currentThreadContextClassLoader (wrapped by a > URLClassLoader, used to load libraries from > ~/lib/)into the ContextFactory and the ContextRunners > retrieve and use the appropriate ClassLoader. > > The DynamicJavaBridgeClassLoader is enabled only when > the procedure java_require() is called. The bridge > allocates a new instance of the > DynamicJavaBridgeClassLoader (with the current loader > as a delegate) and sets it into the > PhpJavaBridgeClassLoader. After the request is done, > the DynamicJavaBridgeClassLoader is thrown away. This > is necessary because the VM keeps a native cache which > is associated the instance of the > DynamicJavaBridgeClassLoader. -- Some Java VM's (IBM) > even crash, if we do dirty tricks to recycle the > instance for new requests (see documentation note in > DynamicClassLoader#copyInto). > > Furthermore the ContextFactory's have been cleaned up. > Both, the pure PHP- as well as the C implementation > now pass the current context ID via a protocol header > field, so that the ContextFactory can temporarily set > the correct JavaBridge instance for the current > connection (see option java.persistent_connections). > This means that most of the old "recycle" logic is now > obsolete and has been removed (it may be possible to > keep the old cruft, but it is ugly and very hard to > understand). > > Because of the above change, old php_java.dll or > java.so files < 4.1.0 will likely crash. For version > 4.1.1 I will add a compatibility option which simply > disables java.persistent_connections when the back end > detects an old protocol header. Until then please use > the pure PHP implementation ("Java.inc") instead. > > > Regards, > Jost Boekemeier |
