[jboss-jira] [JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
Nuno Godinho de Matos (JIRA)
issues at jboss.org
Mon Aug 28 17:36:00 EDT 2017
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454926#comment-13454926 ]
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.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
More information about the jboss-jira
mailing list