Hello,<br><br>A quick fix is to add either :<br>-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog<br>or<br>-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger<br>in the last command of /usr/bin/fop :<br>
run_java -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog $HEADLESS org.apache.fop.cli.Main "$@"<br><br>The longer answer is that according to<br><a href="http://commons.apache.org/logging/guide.html#Configuration">http://commons.apache.org/logging/guide.html#Configuration</a><br>
the default loggin backend is log4j backend if it is found in the classpath.<br>Otherwise, the default is to use the JDK 1.4 Logging backend.<br>The default backend is overloaded with the org.apache.commons.logging.Log option.<br>
<br>When using the log4j backend a log4j.properties is searched in the classpath.<br>Otherwise the "No appenders could be found for logger" is displayed<br>and the errors messages are not displayed.<br><br>The reason log4j is found in the classpath<br>
is that it is in the classpath of the manifest of commons-loggin.jar.<br>This is implemented by the patch 06_classpath_manifest.patch<br>of the commons-logging package.<br>So maybe the bug should belong to commons-logging instead ?<br>
<br>One solution would be to add a log4j.properties files to fop<br>or to explicitly change the backend with the<br>org.apache.commons.logging.Log option<br>(but the same problem may occur in other packages).<br><br>Another solution is to remove the log4j package from the<br>
classpath of commons-logging manifest<br>(I guess it should not break things).<br>The good thing is that the backend selection process of<br>commons-logging would select the JDK 1.4 backend<br>unless log4js is explicitly in the classpath.<br>
<br>I've never used commons-logging so parts of what I'm saying<br>may not be accurate.<br><br>-- <br>Gabriel<br><br>