[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ] Nuno Godinho de Matos commented on WFCORE-3210: ----------------------------------------------- Hi James, Let me try to explain the elements of my configuration. First, you have the subsytem logging configuration. It looks like this. {panel} <subsystem xmlns="urn:jboss:domain:logging:3.0"> <console-handler name="CONSOLE"> <level name="INFO"/> <formatter> <named-formatter name="COLOR-PATTERN"/> </formatter> </console-handler> <custom-handler name="ROOT_WILDFLY_TO_LOG4J" class="com.company.logging.wildfly.CompnayJulToLog4jHandler" module="compnay.logginglog4j1"> <properties> <property name="jbossServerLogDir" value="${jboss.server.log.dir}"/> </properties> </custom-handler> <logger category="com.arjuna"> <level name="DEBUG"/> </logger> <logger category="org.jboss.jca"> <level name="INFO"/> </logger> <logger category="org.jboss.as.connector"> <level name="INFO"/> </logger> <logger category="org.jboss.as.config"> <level name="INFO"/> </logger> <logger category="sun.rmi"> <level name="WARN"/> </logger> <root-logger> <level name="INFO"/> <handlers> <handler name="CONSOLE"/> <handler name="ROOT_WILDFLY_TO_LOG4J"/> </handlers> </root-logger> <formatter name="PATTERN"> <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (thread: %t) %s%e%n"/> </formatter> <formatter name="COLOR-PATTERN"> <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (thread: %t) %s%e%n"/> </formatter> </subsystem> {panel} Second, the jboss-deployment-structure.xml will not help, because that is a per-deployment solution. And what we aim here to have, is a cross cutting logging solution that fits all the applications we deploy into a single instance. So all of our war files go without any log4j configuration. They all log into the same set of log files, and when they need isolation - e.g. a dedicate log file per http client IP address, they would be able to use MDC logging for example to have their dedicate log files. As an example of one type of appenders we have. In any case, just like you have the CONSOLE appender set at wildfly standlone application level - which really helps at development time. Nice to have a console logging. You have the more useful loggers at productive time on this log4jwildfly.properties configuration. So 2nd. The 2nd step on the configurations is that on any domain we create, during domain creation, we manufacture into: WildlyInstallation/user_projects/domains/myStandAloneDomain/configuration/ a log4jwildfly.properties. By the way, if the above folder achitecture looks strange to you. That is related to the fact that we can have multiple domains created for differrent applications, and we do not want a soup of domains in the main wildfly product folder. And second developers are familiar with weblogic organization for domains - so we keep things as familiar as possible. So to summarize - on the stand alone domains we create, on that configuration folder where you find the standalone.xml, you would also find the log4jwildfly.properties created dynamically at domain creation time that we want to use as our main logging configuration - where our appenders are being named and configured. This configuration we put in there, will be read by our custome handler, as soon as it knows where the wildfly server.log.dir is. 3rd - We can talk abut the module definition, for this router appender that we pump into the logging subsytem configuration. It looks as follows. {panel} <?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.1" name="company.logginglog4j1"> <resources> <!-- The pure log4j implementation we want to use --> <resource-root path="log4j-1.2.17.jar" /> <!-- Our appenders --> <resource-root path="company-logging-log4j-1.0.1.jar"/> <!-- Wildfly to log4j routing --> <resource-root path="company-wildfly-logging-tool-1.0.0-SNAPSHOT.jar"/> <!-- This could be interesting if we wanted to add log4j properties file in this folder to be looked up by the module code. --> <resource-root path="."/> </resources> <dependencies> <!-- This where we dump the log4j implementation libraries that we will need to use. --> <!-- module name="company.org.apache.log4j1" /--> <!-- The wildfly bundled implementation we DO NOT want to use. It routes the logManager - and we do not want this. In addition it is isolated in such a manner thta it would not accept any additional appenders unless we hack the module resources to include our own appenders. Using a Logger from this package ensures infinite recursive logging cause by our routing handler. --> <module name="org.jboss.log4j.logmanager"> <exports> <exclude path="/**" /> <exclude path="**" /> </exports> <imports> <exclude path="/**" /> <exclude path="**" /> </imports> </module> <module name="org.apache.log4j"> <exports> <exclude path="/**" /> <exclude path="**" /> </exports> <imports> <exclude path="/**" /> <exclude path="**" /> </imports> </module> <!-- Depends on the jbos log manager due to its extend java util logg class. --> <module name="org.jboss.logmanager"> <imports> <include path="org/jboss/logmanager/ExtLogRecord" /> </imports> </module> <module name="org.slf4j"> <imports> <include path="org/slf4j" /> </imports> </module> {panel} Essentially, at the top of the module we name three jars. A specific log4j implementation version. A jar file containing our particular appenders that we want to keep using - which we already use e.g. in weblogic and that will not only give us the logging that we want to have, but a familiar logging - which is also very important. Third it has a jar file, that is dedicated to routing the LogRecord from the wildfly LogManater JUL logging to Log4j. And this router module is some times getting burned by the org.jboss.log4j module. Normally, at domain time creation. And then when you switch between ways of starting wildfly. Swithing to start via eclipse gives you problems the first time. Switching back to start via bat file gives you problems the first time. So right now - logging is working as we want it to work. But we are required to do a frivolous start and stop of the app server to survide the class loading problem. And then we are OK. Many thanks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)