New SystemOuts since upgrade to 2.0.0.GA with Jboss AS (like

[dermas]

As stated in my previous posts I upgraded from Jboss AOP 1.5.6.GA to 2.0.0.GA

I run my project as ejb in Jboss AS 4.2.2.GA(I upgraded the aop deployer to 2.0.0.GA)

With 1.5.6.GA I had no sysouts on my clientside console. But since the update I get sysouts like the following on my clientside console(not the jboss as console):

[...]
[aop-trace] org.jboss.remoting.transport.socket.SocketWrapper constructing org.jboss.remoting.transport.socket.ClientSocketWrapper instance for Socket[addr=localhost/127.0.0.1,port=3873,localport=1563], using timeout 0
[aop-trace] org.jboss.remoting.transport.socket.SocketWrapper ClientSocketWrapper[Socket[addr=localhost/127.0.0.1,port=3873,localport=1563].1de4376] setting timeout to 0
[aop-trace] org.jboss.remoting.transport.socket.ClientSocketWrapper ClientSocketWrapper[Socket[addr=localhost/127.0.0.1,port=3873,localport=1563].1de4376] getting output stream from Socket[addr=localhost/127.0.0.1,port=3873,localport=1563], org.jboss.remoting.marshal.serializable.SerializableMarshaller@11f139b
[aop-trace] org.jboss.remoting.serialization.impl.java.JavaSerializationManager Creating ObjectOutputStream
[aop-trace] org.jboss.remoting.transport.socket.ClientSocketWrapper ClientSocketWrapper[Socket[addr=localhost/127.0.0.1,port=3873,localport=1563].1de4376] getting input stream from Socket[addr=localhost/127.0.0.1,port=3873,localport=1563], org.jboss.remoting.marshal.serializable.SerializableUnMarshaller@1402eeb
[aop-trace] org.jboss.remoting.serialization.impl.java.JavaSerializationManager Creating ObjectInputStreamWithClassLoader
[aop-trace] org.jboss.remoting.transport.socket.SocketWrapper ClientSocketWrapper[Socket[addr=localhost/127.0.0.1,port=3873,localport=1563].1de4376] setting timeout to 0
[aop-debug] org.jboss.remoting.transport.socket.ClientSocketWrapper reset timeout: 0
[aop-trace] org.jboss.remoting.transport.socket.MicroSocketClientInvoker SocketClientInvoker[d1a1ab, socket://127.0.0.1:3873] writing version 22 on output stream
[...]l

How can I turn those sysouts off?

[flavia.rainone]

Are you running aop on the client side with verbose mode enabled?

[dermas]

Are you running aop on the client side with verbose mode enabled?

Yap a part of the aop classes are on the clientside, but I think I did not enable verbose mode:

I am using precompiled classes with:

<aopc compilerclasspathref="aopc.classpath" verbose="true">

but

<aopc compilerclasspathref="aopc.classpath" verbose="false">

does only stop the sysouts while executing the ant target. The sysouts while using the ejb are still there.

[dermas]

No idea? This might be a reason why I have to rollback to 1.5.6. :/ But I'd like to use an up to date version.

[dermas]

Just some more info:

The sysouts come from the class:

package org.jboss.aop.util.logging;

/**
 *
 * @author <a href="[e-mail]">Kabir Khan</a>
 * @version $Revision: 1.1 $
 */

public class SystemOutLoggerPlugin implements LoggerPlugin

The methods used are:

public void debug(Object message)
{
 print("[aop-debug]", message, null);
}

public void trace(Object message)
{
 print("[aop-trace]", message, null);
}

I noticed that the same debug method is used, when executing the aopc precompile task with verbose = true
It is ok, when it is used during the aopc precompile task, but I dont want it, when executing my ejbs(loadtime weaving is off) :/


Btw. I deployed my project on tomcat 5 with axis 1.4. and there i got no sysouts on my clientside console. So maybe it has something to do with the Jboss AS? But I cant believe that since the sysouts are on the clientside.

[dermas]

I think I found the problem in the following class:

package org.jboss.aop.util.logging;

/**
 * A thin wrapper around the jboss logging framework, so that if a proper logger is not installed
 * we get the output redirected to System.out.
 *
 * @author <a href="[e-mail]">Kabir Khan</a>
 * @version $Revision: 1.1 $
 */
public class AOPLogger{

So the javadoc says that the output is redirected to System.out. if not a proper logger is installed.

A quickfix was the following:

private AOPLogger(final Class<?> clazz)
 {
 org.jboss.logging.Logger log;
 log = org.jboss.logging.Logger.getLogger(clazz);
 if(log.getLoggerPlugin().getClass().getName().equals( org.jboss.logging.NullLoggerPlugin.class.getName()))
 {
 //MY QUICKFIX: commented these two lines out
//org.jboss.logging.Logger.setPluginClassName(SystemOutLoggerPlugin.class.getName());
//log = org.jboss.logging.Logger.getLogger(clazz);
 }

 logger = log;
 }

And poof, the sysouts while executing my ejb were gone, but the debug sysouts while using the aopc precompile task were still there. Just as I want it.
But this is a very dirty fix directly in the jboss aop libs.. Isn't there another way to fix this problem?

[dermas]

Just another opinion:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=135287

Ah I figured it out - AOPLogger is replacing NullLoggerPlugin with SystemOutLoggerPlugin. That seems undesirable, but it's more of an AOP problem than a MC problem it seems.

[kabirkhan]

Ståle will take a look since he has worked on this
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=141369

It seems the messages you are getting are not from JBoss AOP (they are only output when using -Djboss.aop.verbose=true), but rather from other frameworks. It looks like aop is replacing the logger anyway despite the efforts taken in https://jira.jboss.org/jira/browse/JBAOP-623

[stalep]

im looking into this now.
it seems like ive misunderstood how NullLoggerPlugin is used, i always assumed that it was only used if no logger was set. i didnt think that people might use it deliberately. this changes everything and ill remove the check that inserts the aoplogger for now and see if there is another solution to the problem.

[dermas]

Thanks for your feedback :)

[stalep]

the problem was that AOPLogger would globally overwrite the loggerplugin settings even though it was only ment to do that for aopclasses if only the NullLoggerPlugin was used. we want this so that people using aop standalong have a easy way to display debug information without needing to setting up a logger themself. - and AOPLogger will always print out every debug/trace/error statement because it doesnt do any "Level" check, we do that internally in aop (thats what jboss.aop.verbose is for :).
ive added a new line into the if-block that sets the logger back to NullLoggerPlugin after we've created a logger for the aopclasses. hopefully this should fix the problem you were seeing.

[dermas]

the problem was that AOPLogger would globally overwrite the loggerplugin settings even though it was only ment to do that for aopclasses if only the NullLoggerPlugin was used. we want this so that people using aop standalong have a easy way to display debug information without needing to setting up a logger themself. - and AOPLogger will always print out every debug/trace/error statement because it doesnt do any "Level" check, we do that internally in aop (thats what jboss.aop.verbose is for :).
ive added a new line into the if-block that sets the logger back to NullLoggerPlugin after we've created a logger for the aopclasses. hopefully this should fix the problem you were seeing.

Thx, works ;)

[sburdan]

I had experienced a similar problem with lots of [aop-trace] output running a client code against JBoss server The problem has gone away, when jboss-logging-log4j.jar was placed in client CLASSPATH. Apparently, default logging is done by org.jboss.logging.Log4jLoggerPlugin, which was missing from classpath, and SystemOutLoggerPlugin was used instead.