[jboss-jira] [JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently

Tue Aug 29 02:50:00 EDT 2017

    [ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454965#comment-13454965 ] 

Nuno Godinho de Matos edited comment on WFCORE-3210 at 8/29/17 2:49 AM:
------------------------------------------------------------------------

The appenders mentioned in the log4jwildfly.properties they are normal lo4j 1 appenders.

But the one that is a custom handler that is being added to the logging subsystems that is definitely just a simple JUL appender with router functionality.

I mean I completely understand that the logging subsystems is load the log4j module as you explained. In this way it can route the log4j events to the logmanager.
And in fact I tried your module configuration solution  this weekend. And it does not work for one reason, when you take that module and you tell it to reconfigure itself using the property configurator it behaves as if the log4j?early.properties had an additional appender I have not configured to route to the logmanager. Therefore the log4j on wildfly base module is booby trapped to always put logevents into the logmanager and that would create infinite logging.

On the point that module subsystem is fore sure ensuring class isolation, then there is a phenomenal to be understood.
That is why does the current approach work all the time except on the first startup of wildfly?
Why is it that the normal behaviour I get is that my appender can be isolated from the subsytem loaded log4j implementation most of the time, but not on my first try to start wildfly on an arbitrary startup mode. Either via  eclipse or startup bat.

I am quite certain there is a bug.
The fact that I get this mixed behaviour is one the reasons.
But there is another.
I know that it really does not matter whether or not wildfly when booting up the log susbystem will boot up log4j Jboss implementation to route to the logmanager.
Why because I know that my custom appender is banned form even manipulating the JUL LogRecord extension from wildfly that is pumped with all attional metadata such as MDC context thread name and such
If only appender I want to get access to this class I must ensure that I say that my module where my router appender extis depends on org.jbss.logmanager. otherwise I get class definition of found exception or something of the sort.
So that means by appender module is in general! Isolated from even using the jul LogRecord it is being handed over to handle
That means the default behaviour is correct. And the fact that the subsytem has loaded log4j on version A should be irrelevant for my handler because it is an isolated module that does not want to mess around with any classes from that knows module.

I believe there is a bug here.
- The behavior is not deterministic
- The behavior typically demonstrates the class isolation that the module architecture is working most of the time
- It also shows that sometimes as a side effect of depending org.jboss.logmanager you module class loader is soiled but the log4j packages.
And the module architecture apparently should allow a module A (our routing module) to depend on a module B (org.jboss.logmanager) without being forced to be corruped by all the dependnecies e.g module C (org.jboss.log4j) that are transitive to module B.

And this behavior seems to work most of the time but not all of the time.

- I believe I will ask for permission to give you a configuration with this router logger.
To demonstrate the issue on startup.
Because then you would quite clearly see that there is a problem here.

Many thanks for all the Input.

was (Author: nuno.godinhomatos):
The appenders mentioned in the log4jwildfly.properties they are normal lo4j 1 appenders.

But the one that is a custom handler that is being added to the logging subsystems that is definitely just a simple JUL appender with router functionality.

I mean I completely understand that the logging subsystems is load the log4j module as you explained. In this way it can route the log4j events to the logmanager.
And in fact I tried your module configuration solution  this weekend. And it does not work for one reason, when you take that module and you tell it to reconfigure itself using the property configurator it behaves as if the log4j?early.properties had an additional appender I have not configured to route to the logmanager. Therefore the log4j on wildfly base module is booby trapped to always put logevents into the logmanager and that would create infinite logging.

On the point that module subsystem is fore sure ensuring class isolation, then there is a phenomenal to be understood.
That is why does the current approach work all the time except on the first startup of wildfly?
Why is it that the normal behaviour I get is that my appender can be isolated from the subsytem loaded log4j implementation most of the time, but not on my first try to start wildfly on an arbitrary startup mode. Either via  eclipse or startup bat.

I am quite certain there is a bug.
The fact that I get this mixed behaviour is one the reasons.
But there is another.
I know that it really does not matter whether or not wildfly when booting up the log susbystem will boot up log4j Jboss implementation to route to the logmanager.
Why because I know that my custom appender is banned form even manipulating the JUL LogRecord extension from wildfly that is pumped with all attional metadata such as MDC context thread name and such
If only appender I want to get access to this class I must ensure that I say that my module where my router appender extis depends on org.jbss.logmanager. otherwise I get class definition of found exception or something of the sort.
So that means by appender module is in general! Isolated from even using the jul LogRecord it is being handed over to handle
That means the default behaviour is correct. And the fact that the subsytem has loaded log4j on version A should be irrelevant for my handler because it is an isolated module that does not want to mess around with any classes from that knows module.

Soithinkthereismost definitely about here.

Many thanks for all the Input.

> 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)