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

[Nuno Godinho de Matos (JIRA)]

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

Nuno Godinho de Matos edited comment on WFCORE-3210 at 8/31/17 4:57 AM:
------------------------------------------------------------------------

Understood.

I Hope it is now clear what we want to achieve.
I would also mention that on the topic of what we are trying to achieve, there is a reference to an online blog entry where a person has done exactly the same thing that we want to do here except the JUL logging is routed to Log4j2... This reference was added on the Wildfly forum discussion, where I initially asked for help on how to achieve this goal but using log4j1.


As for Stack traces.
There are none. Otherwise they would have naturally been added to the issue - as well as on the Wildfly Forum - where I originally started a discussion on trying to understand how to resolve this problem.
There are no stack traces because you have at logging Level something exploding, and the logging Implantation log4j1 is handling this log explosion situation by doing a STDERR println to report on the issue encountered with the class loader. 

As for the Module configuration.
Yes, the module configuration looks like a patch work indeed.
And yes, some of the comments are a bit out dated - because I did make several experiments, including trying to not bundle log4j1.17 and trying to use the org.jboss.log4j instead - which yielded me the infinite recursive logging issue.

The reason why the module looks this complicated is none-other then the result of multiple Experiments to try to ultimately ban org jboss log4j classes from sneaking into this handler module. That is why you also see all of those excludes with wild card paths...

You can be certain, I did not start by writing a module as complicated looking as you see in the reference panel. That is where i ended up.

Thanks.




was (Author: nuno.godinhomatos):
Understood.

I Hope it is now clear what we want to achieve.
I would also mention that on the topic of what we are trying to achieve, there is a reference to an online blog entry where a person has done exactly the same thing that we want to do here except the JUL logging is routed to Log4j2...


As for Stack traces.
There are none. Otherwise they would have naturally been added to the issue - as well as on the Wildfly Forum - where I originally started a discussion on trying to understand how to resolve this problem.
There are no stack traces because you have at logging Level something exploding, and the logging Implantation log4j1 is handling this log explosion situation by doing a STDERR println to report on the issue encountered with the class loader. 

As for the Module configuration.
Yes, the module configuration looks like a patch work indeed.
And yes, some of the comments are a bit out dated - because I did make several experiments, including trying to not bundle log4j1.17 and trying to use the org.jboss.log4j instead - which yielded me the infinite recursive logging issue.

The reason why the module looks this complicated is none-other then the result of multiple Experiments to try to ultimately ban org jboss log4j classes from sneaking into this handler module. That is why you also see all of those excludes with wild card paths...

You can be certain, I did not start by writing a module as complicated looking as you see in the reference panel. That is where i ended up.

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)