Thread: [Php-java-bridge-users] ClassCastExceptions in standalone deployment

I tried running my website with the standalone, command-line deployment
of the Java Bridge...

 $ java -jar JavaBridge.jar SERVLET:8080

...which seemed to work well.  That is, until a random line of code,
which normally executes just fine, started throwing a ClassCastException
each time it was encountered:

  self::$jaxbContext =3D new JavaClass('javax.xml.bind.JAXBContext');
  self::$talkContext =3D
self::$jaxbContext->newInstance('org.indivo.xml.talk');

Once the CCE appeared, my application could not recover until I
restarted the Bridge and Apache.

I'd never had a problem with those lines with 3.0.7 using the PHP
extension, and I don't see the problem at all while running 4.0.7 from
Tomcat.  Does such a scenario ring any bells?  (Exception text pasted
below.)

Thanks for your help,
Jonathan



[[o:Exception]:"java.lang.Exception: Invoke failed:
[[c:JAXBContext]]->newInstance((o:String)[o:String]). Cause:
java.lang.ClassCastException:
com.sun.xml.bind.v2.runtime.JAXBContextImpl Responsible VM:
1.5.0_08@http://java.sun.com/" at:
#-14 javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:149)
#-13 javax.xml.bind.ContextFinder.find(ContextFinder.java:285)
#-12 javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372)
#0 http://localhost:8080/JavaBridge/java/Java.inc(151):
java_ThrowExceptionProxyFactory->getProxy(2, true)
#1 http://localhost:8080/JavaBridge/java/Java.inc(304):
java_Arg->getResult(true)
#2 http://localhost:8080/JavaBridge/java/Java.inc(310):
java_Client->getWrappedResult(true)
#3 http://localhost:8080/JavaBridge/java/Java.inc(489):
java_Client->getResult()
#4 http://localhost:8080/JavaBridge/java/Java.inc(735):
java_Client->invokeMethod(1, 'newInstance', Array)
#5 http://localhost:8080/JavaBridge/java/Java.inc(853):
java_JavaProxy->__call('newInstance', Array)
#6 [inte in http://localhost:8080/JavaBridge/java/Java.inc on line 129

Hi Jonathan,

> [[o:Exception]:"java.lang.Exception: Invoke failed:
>
[[c:JAXBContext]]->newInstance((o:String)[o:String]).
> Cause:
> java.lang.ClassCastException:
> com.sun.xml.bind.v2.runtime.JAXBContextImpl

sounds like a problem internal to JAXBContextImpl.

> Responsible VM:
> 1.5.0_08@http://java.sun.com/" at:
> #-14
>
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:149)

I guess the above class uses a constructor which
requires a different logging API than provided.

Do you have the source code of the above class?


Regards,
Jost Boekemeier



      __________________________________  Yahoo! Clever: Sie haben Fragen? Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever

Hi,

>
javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:149)
> 
> I guess the above class uses a constructor which
> requires a different logging API than provided.
> 
> Do you have the source code of the above class?

according to jad :) the above class it not public nor
does it contain a newInstance() method. I have checked
the j2ee.jar which comes with the latest sun j2ee
server download.

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

Hi again,

for version 4.1.1 it may make sense to throw an
IllegalAccessException when users try to access
internal classes directly. They should call the
appropriate factory procedure to obtain an instance of
the class.

> does it contain a newInstance() method. I have

It doesn't contain a newInstance(String) procedure.


Regards,
Jost Boekemeier


      __________________________________  Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever

We did some research on the JAXBContext class, and found that when most
people had trouble and saw ClassCastExceptions, it was related to the
class loader.  To avoid class loader issues as much as possible, we
started sticking the result of each "new JavaClass(...)" in a static
class (which will persist indefintely), so we'd only have to call it
once per class in all of our code.  This seemed to lessen the problem,
but then we began seeing IllegalArgumentExceptions popping up here and
there, like so:


[[o:Exception]:"java.lang.Exception: Invoke failed:
[[o:ObjectFactory]]->createContactInformation((o:ContactInformationType)
[o:ContactInformationType]). Cause: java.lang.IllegalArgumentException:
argument type mismatch Responsible VM: 1.5.0_08@http://java.sun.com/"
at:
#-9 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
#-8 sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
#-7 sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
#0 http://localhost:8181/JavaBridge/java/Java.inc(151):
java_ThrowExceptionProxyFactory->getProxy(41, true)
#1 http://localhost:8181/JavaBridge/java/Java.inc(304):
java_Arg->getResult(true)
#2 http://localhost:8181/JavaBridge/java/Java.inc(310):
java_Client->getWrappedResult(true)
#3 http://localhost:8181/JavaBridge/java/Java.inc(489):
java_Client->getResult()
#4 http://localhost:8181/JavaBridge/java/Java.inc(735):
java_Client->invokeMethod(38, 'createContactIn...', Array)
#5 http://localhost:8181/JavaBridge/java/Java.inc(853):
java_JavaProxy->__call('createContactIn...', Array)
#6 [internal function]: Java->__call('createContactIn...', Array)
#7 C:\deploy\merged\php-client\IndivoAPI.class.php(708):
Java->createContactInformation(Object(java_InternalJavaObject))


Perfectly functional methods are now rejecting perfectly good arguments,
also pointing toward class loader issues.  It bears repeating that we're
using version 4.0.7 now, and never saw such issues with v3.0.7.  We even
checked out the trunk from CVS and built the latest-and-greatest, and
still saw these problems.  To be completely transparent, we also need to
mention that almost all of the classes that we're working with have
either been generated by JAXB or are part of the JAXB API.  I think JAXB
is a red-herring (it all worked well together in php-java-bridge 3.0.7)
but its worth mentioning.

One last fact... We've run the JavaBridge through Tomcat and in
standalone mode (java -jar...) and the problem seems to arise much
"quicker" when we run in Tomcat.  The errors are sporadic in both and
happen in different locations each time. Sometimes a method invocation
will succeed in one run and then fail in another.

We want to be as helpful as possible while trying to resolve this issue.
What other information can we send you to help isolate the problem?

Thanks,
Jon Abbett & Bill Simons
Children's Hospital Boston

P.S. How do I specify where to write the log file in a Tomcat-deployed
Java Bridge?



> -----Original Message-----
> From: php...@li...=20
> [mailto:php...@li...]=20
> On Behalf Of php...@li...
> Sent: Wednesday, June 06, 2007 5:15 AM
> To: php...@li...
> Subject: Re: [Php-java-bridge-users] ClassCastExceptions in=20
> standalone deployment
>=20
> Hi Jonathan,
>=20
> > [[o:Exception]:"java.lang.Exception: Invoke failed:
> >
> [[c:JAXBContext]]->newInstance((o:String)[o:String]).
> > Cause:
> > java.lang.ClassCastException:
> > com.sun.xml.bind.v2.runtime.JAXBContextImpl
>=20
> sounds like a problem internal to JAXBContextImpl.
>=20
> > Responsible VM:
> > 1.5.0_08@http://java.sun.com/" at:
> > #-14
> >
> javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:149)
>=20
> I guess the above class uses a constructor which
> requires a different logging API than provided.
>=20
> Do you have the source code of the above class?
>=20
>=20
> Regards,
> Jost Boekemeier
>=20
>=20
>=20
>       __________________________________  Yahoo! Clever: Sie=20
> haben Fragen? Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever
>=20
>=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

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

> 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

> > 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

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

> 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,

I could not reproduce this, but I think I see the
problem: The classloaded referenced by the current
thread context is out of sync with the classloader
kept by the bridge.

This may happen when persistent connections are used,
but the bridge does not call recycle() at the end of
the script. This happens when the pure PHP
implementation is used, which uses a different path
than the C implementation.

As a workaround please modify your Java.inc and change
the "pfsockopen" to "fsockopen" (all occurences).

However, this problem should be fixed in version
4.1.1. (The current test version is 4.1.0b, please use
the link
http://sourceforge.net/project/downloading.php?group_id=117793&use_mirror=osdn&filename=php-java-bridge_4.1.0_j2ee.zip&15111070).


> command line.  Version 4.1.1 doesn't exist -- you
> just released 4.1.0a yesterday, right?

Yes, it is a test version, which is currently hidden.


> java.lang.IllegalStateException: java_require() not

That was a bug in 4.1.0a, the
DynamicJavaBridgeClassLoader was switched off in
4.1.0a, so java_require() failed. It is enabled again
in 4.1.0b.


Regards,
Jost Boekemeier


__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com 

Hi,

> I could not reproduce this

okay, I could reproduce this now. We actually have a
feature test which checks if the current thread
context class loader is out of sync with the java
bridge class loader.

But this problem happens only when persistent
connections are used, not with a named pipe
communication channel.


Regards,
Jost Boekemeier





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