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

> Do you use the GlobalPhpJavaServlet or do you have
> only one JavaBridge.war web application?

We've only ever run one JavaBridge.war web application.

> Since version > 3.0.8 the PHP/Java Bridge used a class
> loader cache, which means that there was only one
> class loader for all shared web applications.
>=20
> But this is only an issue if the is a JavaBridge.jar
> in the global classpath, which is not the recommended
> setup. From the FAQ of version 4.1.1:

We've only ever run the JavaBridge.war or run JavaBridge.jar from the
command line.  Version 4.1.1 doesn't exist -- you just released 4.1.0a
yesterday, right?

> Do you have the JavaBridge.jar in the global
> classpath?

Nope.

So, we just downloaded the 4.1.0 release (thanks for replacing it) and I
tried it in Tomcat and standalone.  Either way, the first time I run my
test script after starting the bridge it works fine.  The second time, I
get a "protocol error," and the third time my browser just hangs trying
to make the request.  I opened my Java Bridge log and saw that this had
occurred the second time I ran my script:

Jun 14 16:06:28 JavaBridge ERROR: An exception occured:
java.lang.IllegalStateException: java_require() not allowed for the HTTP
tunnel. Use a context runner instead.
java.lang.IllegalStateException: java_require() not allowed for the HTTP
tunnel. Use a context runner instead.
	at
php.java.bridge.JavaBridgeClassLoader.checkCl(JavaBridgeClassLoader.java
:46)
	at
php.java.bridge.SimpleJavaBridgeClassLoader.getClassLoader(SimpleJavaBri
dgeClassLoader.java:172)
	at php.java.bridge.Request.setBridge(Request.java:493)
	at
php.java.bridge.http.ContextFactory.recycle(ContextFactory.java:212)
	at
php.java.bridge.http.ContextFactory.recycle(ContextFactory.java:253)
	at php.java.bridge.Parser.parse(Parser.java:225)
	at php.java.bridge.Request.handleRequest(Request.java:334)
	at php.java.bridge.Request.handleRequests(Request.java:388)
	at
php.java.bridge.http.ContextRunner.run(ContextRunner.java:165)
	at
php.java.bridge.BaseThreadPool$Delegate.run(BaseThreadPool.java:58)

(Happened on the line where I load my jars using java_require)

First I've seen this error -- how do I "use a context runner"?

Thanks,
Jon

Hi Jonathan,

> problem most often when
> the Bridge is running in Tomcat. 

ah, I think I've missed that information.

Do you use the GlobalPhpJavaServlet or do you have
only one JavaBridge.war web application?

Since version > 3.0.8 the PHP/Java Bridge used a class
loader cache, which means that there was only one
class loader for all shared web applications.

But this is only an issue if the is a JavaBridge.jar
in the global classpath, which is not the recommended
setup. From the FAQ of version 4.1.1:
-----------------------------------------

I have two different classes with the same name in two
different web apps. When using the
GlobalPhpJavaServlet, the bridge uses only one of
these classes!?!


This is a known bug in all PHP/Java Bridge versions <
4.1.0.

Please upgrade to a PHP/Java Bridge version >= 4.1.0
or use a PHP/Java Bridge version <= 3.0.8 and switch
off persistent connections:
java.persistent_connections=Off.

Since version 4.1.0, the PHP/Java Bridge correctly
uses the current thread context class loader so that,
when the Java.inc is loaded from a webApp, the class
loader from that web application is used. For example:


require_once("http://localhost:8080/webApp1/java/Java.inc");
echo java("my.TestClass")->getId(); // assuming that a
getId() procedure exists
=> TestClass of webApp1

require_once("http://localhost:8080/webApp2/java/Java.inc");
echo java("my.TestClass")->getId(); // assuming that a
getId() procedure exists
=> TestClass of webApp2

--------------------------------------

Do you have the JavaBridge.jar in the global
classpath?


> How do I configure
> the Tomcat-deployed
> Bridge to put its log file in the directory of my
> choosing?

Please start tomcat as follows (assuming you are
running tomcat under Linux):

export
JAVA_OPTS="-Dphp.java.bridge.default_log_level=4
-Dphp.java.bridge.default_log_file=/tmp/jb.log"
/opt/apache-tomcat/bin/catalina.sh start


Or please add log4j.jar to the global class path (for
example to /opt/jdk1.5/jre/lib/ext) and start the
log4j log viewer with the command:

java -cp /opt/jdk1.5/jre/lib/ext/log4j.jar
org.apache.log4j.chainsaw.Main


After you restart tomcat, the log will appear in the
log4j window, which allows you to search for certain
events etc.


Regards,
Jost Boekemeier




		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

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

> > Can you please open a problem report, and attach code
> > which allows us to reproduce the problem? And/or
> > please  set the log level to 4 and attach the log at
> > the end of the ticket.

I managed to recreate the original problem we saw (ClassCastExceptions)
with a test script using the standalone bridge.  I've packaged
everything up (including a log) and have created a ticket on
SourceForge.

Best,
Jonathan=20

> It is certainly possible to load classes so that
> class@classLoader1 is assignment-incompatible to
> class@classLoader2.=20
>=20
> But I don't see this as a problem of the PHP/Java
> Bridge. -- When the request is done all versions of
> the PHP/JavaBridge allocate a new
> DynamicJavaBridgeClassLoader to avoid such problems
> (one class coming from the VM cache, the other one
> from the loader).

Assuming for a moment that there may be a classloader issue, do you
think it might be safer for us to put all our jars in one of the
directories the Bridge loads by default, rather than use java_require()?

> Can you please open a problem report, and attach code
> which allows us to reproduce the problem? And/or
> please  set the log level to 4 and attach the log at
> the end of the ticket.

I'd be happy to.  Unfortunately, we don't have any code that can
reliably reproduce the problem -- it comes and goes without notice --
but I'll do my best.  As I've said, we see the problem most often when
the Bridge is running in Tomcat.  How do I configure the Tomcat-deployed
Bridge to put its log file in the directory of my choosing?

Thanks,
Jonathan

Hi Jonathan,

> We did some research on the JAXBContext class, and
> found that when most
> people had trouble and saw ClassCastExceptions

imho the problem you've reported is due to a bug in
your software. You must allocate the class via some
factory.


> class loader.  To avoid class loader issues as much
> as possible, we

It is certainly possible to load classes so that
class@classLoader1 is assignment-incompatible to
class@classLoader2. 

But I don't see this as a problem of the PHP/Java
Bridge. -- When the request is done all versions of
the PHP/JavaBridge allocate a new
DynamicJavaBridgeClassLoader to avoid such problems
(one class coming from the VM cache, the other one
from the loader).

However, the code example you have given cannot work.

Can you please open a problem report, and attach code
which allows us to reproduce the problem? And/or
please  set the log level to 4 and attach the log at
the end of the ticket.


Regards,
Jost Boekemeier





	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de