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

> But now that it came all clear, you can set the log4j logger to listen on a
> different port:
>

Well, I don't like configuration options; software should just work. In my
opinion adding a configuration option to work around a bug in some external
software component is a bad idea. I think the jboss developers are to blame,
because they use a well known service end point for their internal
communication purpose.

I will have a look at this issue when I prepare version 5.5.4.1. In the
worst case, we need to switch off chainsaw if we're running within the jboss
app server or if we detect that the service listening on port 4445 is not
chainsaw.


Regards,
Jost Boekemeier

On Monday 30 November 2009, php...@li... wrote:
> This port clash seems to be a common problem in jboss 4. See
> http://www.thedance.net/~roth/TECHBLOG/jbossports.html
> Changing the ports as suggested should solve the problem.

Oh, 1000 thanks, indeed, changing the jboss default port solved the problem.


> I don't think we can do anything here. We can't change the log4j standard
> port and we can't change the jboss defaults.

On the contrary, I'm thinking of at least a couple of things :)

Even if you don't change anything, don't you think that at least it should be 
mentioned in the FAQ perhaps ? :)

In the beginning, it wasn't clear for me that the bridge scans for the port and 
then uses it because the exception I pasted on my original post really doesn't 
help at all.


But now that it came all clear, you can set the log4j logger to listen on a 
different port:

java -Dchainsaw.port=14445 org.apache.log4j.chainsaw.Main

In the same direction, does it make sense to ask for a new feature? 
The port that the bridge scans for, could also be configurable in the same way:
-Dphp.java.bridge.default_log_port=14445
(I see that it is a static final variable in php.java.bridge.ChainsawLogger)

This could eventually help your JBoss users to maintain all jboss default ports 
and just configure the bridge (which is the deployable). And not vice versa :)

If you'd like, I could contribute this small patch.


Thanks for your support! :)

> Regards,
> Jost Boekemeier


-- 
Thanos Kyritsis <djart at linux.gr>

This port clash seems to be a common problem in jboss 4. See
http://www.thedance.net/~roth/TECHBLOG/jbossports.html
Changing the ports as suggested should solve the problem.


I don't think we can do anything here. We can't change the log4j standard
port and we can't change the jboss defaults.


Regards,
Jost Boekemeier

Hi,

> java.net.SocketException: Connection reset

yes, I've seen this bug, but I assumed it was a jboss issue. I didn't
connect it to the java bridge logger until now.


> 1) Starting the log4j viewer is not possible, since it uses port 4445,
which is
> already taken by the JBoss running instance.

This explains both issues, I think. Port 4445 is the standard log4j port.
The bridge scans and uses it as its log output device, if some service is
listening on that port.

If jboss starts another thread listening on that port, the jboss thread will
get confused and the bridge will stop writing the log when it detects that
its 'logger' has crashed.


I will check this issue when I prepare version 5.5.4.1 (either this week or
next week).


Regards,
Jost Boekemeier

Hello,

I'd like to ask for some advice when deploying the php-java bridge on JBoss 
4.2.3.

I'm facing 2 issues:

1) logging

2) An exception when jboss starts

The exception is this one:

ERROR [ServerThread] Failed to initialize
java.net.SocketException: Connection reset
   at java.net.SocketInputStream.read(SocketInputStream.java:168)
   at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
   at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
   at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
   at 
java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2266)
   at 
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2279)
   at 
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
   at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
   at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
   at 
org.jboss.invocation.pooled.interfaces.OptimizedObjectInputStream.<init>(OptimizedObjectInputStream.java:147)
   at 
org.jboss.invocation.pooled.server.ServerThread.dorun(ServerThread.java:265)
   at org.jboss.invocation.pooled.server.ServerThread.run(ServerThread.java:156)


It happens immediately after deploying JavaBridgeTemplate554.war.
Another troubling fact is that sometimes (but very rarely) I don't see this 
exception when JBoss starts. For example, if I do 10 jboss startups, 9 times I 
see this exception and 1 time I don't.

The second issue is the logging. The JavaBridge war somehow gets in the way and 
after it gets deployed it blocks any jboss console logging. I understand that 
this is a somewhat default behaviour as I see in the documentation, however, I'd 
like to solve this if possible and re-enable JBoss console logging. Is it 
possible ?

I'm looking in README.J2EE, it mentions nothing about it, so I'm only left with 
the FAQ. However, the FAQ's instructions on enabling logging do not apply for a 
JBoss environment, because:

1) Starting the log4j viewer is not possible, since it uses port 4445, which is 
already taken by the JBoss running instance.

2) Using -Dphp.java.bridge.default_log_level=5 in JBoss' JAVA_OPTS makes 
absolutely no difference.


I'm currently successfully using the php-java bridge for bridging 2 completely 
remote projects (that communicate with each other), one running on PHP/Apache 
and one running on JBoss. But, if possible, I'd like to solve these JBoss issues 
as well.

I've exploded the JavaBridgeTemplate554.war, expecting to find some related 
properties files (for example log4j.properties, application properties and so), 
but that also didn't help.

Could you please provide some help ? I'm going to use the bridge in a production 
environment but need these issues ironed out! :)

Thanks in advance for any help.

-- 
Thanos Kyritsis <djart at linux.gr>