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

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
>

Hi,

> forget, i have it up and running from source

great. :)






	

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

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

php...@li... wrote:
> php...@li... schrieb:
>> Hi,
>>
>>>> i just downloaded and installed 
>>> php-java-bridge-3.0.7-1.FC4.i386.rpm
>>>> but it doesnt seem to work
>>
>> The FC4 is for FC4 :) The
>> php-java-bridge-3.0.7-1.FC5.i386.rpm doesn't exist
>> yet, but it should be possible to create it from the
>> php-java-bridge-3.0.7*src.rpm (if not, please create a
>> bug report).
> 
> can you point me to clear howto about creating rpm from source rpms? :-/
> sorry for bother you with that ...

forget, i have it up and running from source

thanks for this software


-- 
Sebastian Mendel

www.sebastianmendel.de
www.sf.net/projects/phpdatetime | www.sf.net/projects/phptimesheet

php...@li... schrieb:
> Hi,
> 
>>> i just downloaded and installed 
>> php-java-bridge-3.0.7-1.FC4.i386.rpm
>>> but it doesnt seem to work
> 
> The FC4 is for FC4 :) The
> php-java-bridge-3.0.7-1.FC5.i386.rpm doesn't exist
> yet, but it should be possible to create it from the
> php-java-bridge-3.0.7*src.rpm (if not, please create a
> bug report).

can you point me to clear howto about creating rpm from source rpms? :-/
sorry for bother you with that ...


> We will make FC5 binaries available when FC5 becomes
> available in a few months.

too bad ... ;-)

thanks anyway ...

-- 
Sebastian