Just a FYI, that dependency is now solved.
How, using yet another logging wrapper? If so, another rant is about to errupt.
> How, using yet another logging wrapper? If so, another rant is about to errupt.
I need to support some logging within JBossSerialization, as a way I (or future contributors) could debug it.
If you define org.jboss.serial.LogLevel=5 it will enable tracing on JBossSerialization. There is a class doing that parsing:
The wrapper is pretty small, is more an utility class.
I didn't like the solution itself. Still looking for a better way to do it:
The reason that I wanted to avoid using jboss-common and log4j was just to make easier using JbossSerialization outside of JBoss. (just add a JAR and import the correct package)
Well... as I know you (and everybody else) is going to complain about it, I'm going to change it. lol
I will try to keep using log4j and jboss-commons, but testing for classes availability. (like, if not available, just disabling log).
I will probably need to work with Object on the logger, and create a small parser just to do the type cast.
public class SomeClas
public static Object logger;
public static boolean isLog;
// some initialization on the logger
public void someMethod()
if (isLog) // just to no test for the type if don't need to
The LoggerWrapper will deal with conversions, using reflection so I could have jboss-serialization.jar without having log4j.jar and jboss-commons.jar on the classpath.
The two acceptable logging frameworks are commons-logging and the org.jboss.logging in the jboss common module. One or the other is what you should depend on. So either there is no logging (bad), or you have a dependency on a logging framework.
In terms of the jboss common jar, we have stated a number of times that its too big and needs to be broken up. Someone just needs to do it.