php-java-bridge-users

[Php-java-bridge-users] Problems with InitialNamingFactory

[<php...@li...>]

Hi,

First of all, I would like to say your work is amazing and this is an
incredible tool.  I've gotten the bridge running and everything was looking
good until I tried instantiating JBoss' Initial Naming Context Factory.  My
goal is to run Apache 2 and PHP on the front-end and use the bridge to
connect to an EJB3 Session Bean running on a JBoss AS 4.

I believe this is simply a classpath issue but I have tried placing the JAR=
s
which I think it is looking for in all of the places I can think of.  So
I'll start with a the code.

java_require(" http://localhost/jbossall-client.jar");     // My last resor=
t
was trying to load the jars in this style
java_require(" http://localhost/jnp-client.jar");

$envt =3D array(
        "java.naming.factory.initial" =3D> "org.jnp.interfaces.NamingContex
tFactory",
        "java.naming.factory.url.pkgs" =3D> "
org.jboss.naming:org.jnp.interfaces ",
        "java.naming.provider.url" =3D> "jnp://localhost:1099"
    );

$ctx =3D new Java("javax.naming.InitialContext", $envt);   // At this line =
it
fails...
$cal =3D $ctx->lookup(" stickygroups-ear-0.1/LocalRemoteCalculator/remote")=
;

In the JBoss console I get the following stack trace:

21:59:41,595 INFO  [[/JavaBridge]]  JavaBridge ERROR: Exception occured
21:59:41,595 ERROR [[/JavaBridge]]
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0...
        at sun.reflect.NativeConstructorAccessorImpl.newInstance ...
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance .. .
        at java.lang.reflect.Constructor.newInstance...
        at php.java.bridge.JavaBridge.CreateObject(JavaBridge.java:515)
        at php.java.bridge.Request.handleRequest(Request.java:406)
        at php.java.bridge.Request.handleRequests (Request.java:425)
        at php.java.bridge.http.ContextRunner.run(ContextRunner.java:71)
        at php.java.bridge.ThreadPool$Delegate.run(ThreadPool.java:28)

Caused by: javax.naming.NoInitialContextException :
Cannot instantiate class: org.jnp.interfaces.NamingContextFactory
[Root exception is java.lang.ClassNotFoundException:
Could not find org.jnp.interfaces.NamingContextFactory in java_require()
path]

        at javax.naming.spi.NamingManager.getInitialContext
        at javax.naming.InitialContext.getDefaultInitCtx(
        at javax.naming.InitialContext.init(InitialContext.java:223)
        at javax.naming.InitialContext .<init>(InitialContext.java:197)
        ... 9 more

Caused by: java.lang.ClassNotFoundException:
Could not find org.jnp.interfaces.NamingContextFactory in java_require()
path
        at php.java.bridge.DynamicJavaBridgeClassLoader.loadClass (
DynamicJavaBridgeClassLoader.java:272)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:242)
        at com.sun.naming.internal.VersionHelper12.loadClass
        at javax.naming.spi.NamingManager.getInitialContext
        ... 12 more

Caused by: java.lang.ClassNotFoundException: Class
org.jnp.interfaces.NamingContextFactory not found
        at php.java.bridge.DynamicClassLoader.loadClass(
DynamicClassLoader.java: 379)
        at php.java.bridge.DynamicJavaBridgeClassLoader.loadClass(
DynamicJavaBridgeClassLoader.java:270)
        ... 17 more


The class file it is looking for is in the jnp-client.jar.  The other place=
s
which I have tried placing jnp-client.jar are in the
JavaBridge.war/WEB-INF/lib/
folder, the PHP/ext/lib/ folder, within the actual JavaBridge.jar file, the
java/jre/ext/... folder (which made JBoss break =3D), and about everywhere
else I could imagine including on the http server as in the code above.

I'm temporarily out of ideas for what to try next or where to turn.  Any
advice would be very appreciated.

Cheers,

Kris Jordan

RE: [Php-java-bridge-users] Problems with InitialNamingFactory

[<php...@li...>]

Hi,

> Cannot instantiate class:
> org.jnp.interfaces.NamingContextFactory

assuming that you have copied the 

/usr/share/doc/php-java-bridge-devel-3.0.7/examples/j2ee/documentBean.jar


to the jboss deploy directory and changed globals.php:

// jboss specific changes in globals.php
$app_url="jnp://127.0.0.1:1099";
put("java.naming.factory.initial",
"org.jnp.interfaces.NamingContextFactory");

and documentClient.php:

// jboss specific changes in documentClient.php
java_require("/opt/jboss-4.0.2/client/;/usr/share/doc/php-java-bridge-devel-3.0.7/examples/j2ee/documentBean.jar");
include("globals.php");
$doc=createDocument($app_url, "DocumentEJB");

the example works with jboss, at least when the VM
running the documentBean is different than the VM
running the server part of documentBean (I haven't
tested rmi/iiop within only one VM, yet).


> was trying to load the jars in this style
> java_require(" http://localhost/jnp-client.jar");

The java_require() makes the jnp classes available to
the bridge, only. It does not "inject" the loaded
classes into the application server. 

The above standalone example works because the client
VM loads everything fresh from the bridge classloader
and therefore the jnp-client classes are visible to
the factory.

But if the factory is already available to the global
or jboss class loader and you load the jnp-client via
java_require(), the global or jboss classloader would
still report the jnp-client class as missing unless
you make it available to the global or jboss class
loader. 

BTW: Correct me if I am wrong, but is there a reason
why delegate to the parent loader and then abort when
the parent fails with anything than a
ClassNotFoundException?  I think we should check for
other exceptions and try again w/o the parent; the
code should try to load everything from the user's
java_require path. In this case 
java_require("$jboss_home/client/) would work,
regardless of how many classes the parent has cached.


> In the JBoss console I get the following stack
> trace:
>
php.java.bridge.ThreadPool$Delegate.run(ThreadPool.java:28)
> 
> Caused by: javax.naming.NoInitialContextException :

I think jsp and servlets have the same problem. I mean
there must be some jboss installation instructions
which probably state that one must copy the client jar
file(s) into the webapp class path, to the
WEB-INF/lib/  probably?


I'll check the classpath issue, please see PR 1432361
for details
(http://sourceforge.net/tracker/index.php?func=detail&aid=1432361&group_id=117793&atid=679233).

Thank you very much for the bug report.

However, I think it should be possible to add the
required .jar files to the webapp classpath, but I
have't tried it, yet. I will check the jboss
documentation and add a note to our j2ee sample
documentation for 3.0.8.


Regards,
Jost Boekemeier



	

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

RE: [Php-java-bridge-users] Problems with InitialNamingFactory

[<php...@li...>]

Hi,

I was able to reproduce this problem with our
classloader.

I will switch it off when the backend runs in a
servlet engine or a j2ee application server.

The whole concept of the dynamic classloader doesn't
work when the j2ee server uses two seperate
classloaders for the webapp and for the j2ee classes. 

The org.jnp.interfaces.NamingContextFactory is in the
jboss j2ee classpath, it is not visible to the webapp
classloader. Since the dynamic classloader only
delegates to its parent and doesn't have access to the
jboss j2ee classloader the code:

new Java("org.jnp.interfaces.NamingContextFactory")

always fails when the dynamic classloader is set as
the bridge thread context classloader.

The situation is different when the dynamic
classloader runs within our standalone container, so I
will not remove it entirely. But j2ee or servlet
environments have their own way to handle jar and
class files.

As a workaround please add a policy file which
disables the dynamic classloader, or use a commercial
AS which ships with a reasonable policy file. The Sun
J2EE AS 8.1 for example ships with a default policy
file which denies us to dynamically load classes, so
the dynamic classloader is switched off automatically.


Regards,
Jost Boekemeier





	

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

Re: [Php-java-bridge-users] Problems with InitialNamingFactory

[<php...@li...>]

Jost,

I really appreciate your help looking into this issue.  Unfortunately JBoss
is the only choice I have at the moment.  I'm somewhat new to the J2EE AS
arena and have a newbie question to ask.

Could you give me some direction as to where I would be adding the policy
file or where I should be looking?  Am I disabling the dynamic classloader
in the bridge or for the JavaBridge WAR in the AS?

Thank you,

Kris

On 2/16/06, php...@li... <
php...@li...> wrote:
>
> Hi,
>
> I was able to reproduce this problem with our
> classloader.
>
> I will switch it off when the backend runs in a
> servlet engine or a j2ee application server.
>
> The whole concept of the dynamic classloader doesn't
> work when the j2ee server uses two seperate
> classloaders for the webapp and for the j2ee classes.
>
> The org.jnp.interfaces.NamingContextFactory is in the
> jboss j2ee classpath, it is not visible to the webapp
> classloader. Since the dynamic classloader only
> delegates to its parent and doesn't have access to the
> jboss j2ee classloader the code:
>
> new Java("org.jnp.interfaces.NamingContextFactory")
>
> always fails when the dynamic classloader is set as
> the bridge thread context classloader.
>
> The situation is different when the dynamic
> classloader runs within our standalone container, so I
> will not remove it entirely. But j2ee or servlet
> environments have their own way to handle jar and
> class files.
>
> As a workaround please add a policy file which
> disables the dynamic classloader, or use a commercial
> AS which ships with a reasonable policy file. The Sun
> J2EE AS 8.1 for example ships with a default policy
> file which denies us to dynamically load classes, so
> the dynamic classloader is switched off automatically.
>
>
> Regards,
> Jost Boekemeier
>
>
>
>
>
>
>
>
>
> ___________________________________________________________
> Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> php-java-bridge-users mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users
>

Re: [Php-java-bridge-users] Problems with InitialNamingFactory

[<php...@li...>]

Hi,

I've fixed this bug for version 3.0.8, a snapshot is
here:  


http://php-java-bridge.sourceforge.net/snaps/3.0.8pre/

Can you please start jboss and copy the JavaBridge.war
and documentBean.jar to
$jboss_home/server/default/deploy and run the
documentClient.php test:

 http://localhost:8080/JavaBridge/documentClient.php

I have tested it on a linux machine with jboss 4.x.


> Could you give me some direction as to where I would
> be adding the policy file 

Difficult. It seems that jboss already has a
server.policy file (in the server/default/conf), but
this file grants all permissions. At the moment I have
no idea how to change this, sorry.

But I hope the above snapshot already solves this
problem.


Regards,
Jost Boekemeier



	

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

Re: [Php-java-bridge-users] Problems with InitialNamingFactory

[<php...@li...>]

Jost,

Thanks for such quick response.  That did the trick.  Excellent work.  This
is the most useful PHP plug-in I've ever used.

Kris

On 2/17/06, php...@li... <
php...@li...> wrote:
>
> Hi,
>
> I've fixed this bug for version 3.0.8, a snapshot is
> here:
>
>
> http://php-java-bridge.sourceforge.net/snaps/3.0.8pre/
>
> Can you please start jboss and copy the JavaBridge.war
> and documentBean.jar to
> $jboss_home/server/default/deploy and run the
> documentClient.php test:
>
> http://localhost:8080/JavaBridge/documentClient.php
>
> I have tested it on a linux machine with jboss 4.x.
>
>
> > Could you give me some direction as to where I would
> > be adding the policy file
>
> Difficult. It seems that jboss already has a
> server.policy file (in the server/default/conf), but
> this file grants all permissions. At the moment I have
> no idea how to change this, sorry.
>
> But I hope the above snapshot already solves this
> problem.
>
>
> Regards,
> Jost Boekemeier
>
>
>
>
>
>
>
> ___________________________________________________________
> Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> php-java-bridge-users mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users
>