[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ 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.
> 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)
8 years, 3 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos commented on WFCORE-3210:
-----------------------------------------------
Hi James,
Two things.
First, it would be great if you could guide me to the trick to do what you said in your reply.
Namely, how exactly hand I get my log4jwildfly.properties file configuration - which I do not deploy per application - i want to be using at Widlfly wide level - to get used.
What I have right now, as you have summarized, is the subsytem logging ehanced with a custome handler that does this rooting for the hole wildfly.
And then my handler, once it is configuration with the jboss.server.log.dir - will read the log4jwildfly.properties and set itself to rout to log4j.
And finally, it will also reload its configuration if detects a timestamp change in the log4jwildfly.properties file - to adapt to any dynamic changes set by a user.
There multiple custom handlers in this properties file.
And we have no intention of setting log4j.properties on a per deployment/war configuration.
We want this coinfiguration to be cross cutting for a running instance.
It would be great if there is a better approach than what I am doing.
The second point is the issue I am seing.
So as I explain in the thread.
When I first create a wildfly domain, I typically see on the first startup of the new wildfly standalone domain errors like this:
{panel}
A "org.apache.log4j.PatternLayout" object is not assignable to a "org.apache.log4j.Layout" variable.
2017-08-25 14:50:59,597 ERROR [stderr] (Controller Boot Thread)
log4j:ERROR The class "org.apache.log4j.Layout" was loaded by
2017-08-25 14:50:59,598 ERROR [stderr] (Controller Boot Thread)
log4j:ERROR [ModuleClassLoader for Module "company.org.apache.log4j1:main" from local module loader @5b1d2887
(finder: local module finder @46f5f779 (roots: C:\dev\appserver\wildfly\wildfly-10.1.0.Final\modules,C:\dev\appserver\wildfly\wildfly-10.1.0.Final\modules\system\layers\base))]
whereas object of type
2017-08-25 14:50:59,598 ERROR [stderr] (Controller Boot Thread) log4j:ERROR
"org.apache.log4j.PatternLayout" was loaded by [ModuleClassLoader for Module "org.jboss.log4j.logmanager:main" <----- This guy has common classes
from local module loader @5b1d2887 (finder: local module finder @46f5f779 (roots: C:\dev\appserver\wildfly\wildfly-10.1.0.Final\modules,C:\dev\appserver\wildfly\wildfly-10.1.0.Final\modules\system\layers\base))].
{panel}
This errors then immediately disappear on the 2nd, 3rd an nth deployment.
Then, If I decide I want to start the stanalone domain using eclipse.
i can open eclipse and tell it to start the server.
The first time I do this, I get the above errors of class loading.
If I then stop the server, the 2nd, 3rd and nth tries the startup goes flawlessly and log routing is working perfectly just like I want it to be.
If I stop starting with eclipse, and switch back to starting via bat file, the same story.
The first try I have problems, the 2nd the problems on class loading go away.
And I believe that with the module setup I have shown on the wildfly thread, I simply should never get this class loading error from within the custom handler.
For the custom handler I have written, there simply should exist none of the org.jboss.log4j classes, because the module of this handler is trying by all means possible to ask for wildfly to isolate it from the bundled log4j.
So that is the issue.
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)
8 years, 3 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3210:
---------------------------------------
Oh maybe I see more what you mean now. So you want your own version of log4j to be used in your module correct? That can definitely work and should really work fine. Depending on what exactly you're trying to do you *may* need to exclude the logging subsystem from your deployments with a {{jboss-deployment-structure.xml}}. I'm not really following what your configuration is however.
> 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)
8 years, 3 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3210:
---------------------------------------
Not a problem at all. I just wanted to make sure is all :)
I might be a bit confused on what the actual issue you're seeing is. If you just want to use log4j appenders as a custom-handler you can already do that in WildFly. There is not need to create your own custom {{java.util.logging.Handler}}.
> 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)
8 years, 3 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on WFCORE-3210 at 8/28/17 5:06 PM:
------------------------------------------------------------------------
Hi James, I am using the pure wildly class loading mechanism.
I may have incorrectly called it an OSGI bug.
This is because to me this class-loading module mechanism that looks like it is quite powerful, looked like a red-had/jboss approach for implementing a OSGI like class loading engine.
So to the me the whole module syntax detailing what to export/import from a given module feels like a possible OSGI/like implementation.
In any case, the architecture of the module system of wildfly is supposed to be able to cope with the different jar files versions for the same type of implementation (e.g. multiple modules of log4j) if each module is properly isolated from another.
I would expect that the custom handler by naming the module that implement is - and the module that implements it by detailing that it wants to use a specific log4j implementation and exclude all classes from the org.jboss.log4j module, should always be ensured to never have the problem of code running in the scope of this module to have been loaded from a different module we do not depend upon.
So that is the main point.
But ultimately this why I called osgi.
I am sorry if this has created confusion.
Many thanks.
was (Author: nuno.godinhomatos):
Hi James, I am using the pure wildly class loading mechanism.
I may have incorrectly called it an OSGI bug.
This is because to me this class-loading module mechanism that looks like it is quite powerful, looked like a red-had/jboss approach for implementing a OSGI like class loading engine.
So to the me the whole module syntax detailing what to export, what to import from a given module felt like a possible OSGI implementation.
This may not be correct on my side.
But to a certain extend it does feel like that in any case the architecture of the module system of wildfly is supposed to be able to cope with the different jar files versions for the same type of implementation (e.g. multiple modules of log4j) if each module is properly isolated for another.
But ultimately this why I called osgi.
I am sorry if this has created confusion.
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)
8 years, 3 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3210:
----------------------------------
Description:
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.
was:
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 OSGI subsystem, 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.
> 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)
8 years, 3 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on WFCORE-3210 at 8/28/17 5:02 PM:
------------------------------------------------------------------------
Hi James, I am using the pure wildly class loading mechanism.
I may have incorrectly called it an OSGI bug.
This is because to me this class-loading module mechanism that looks like it is quite powerful, looked like a red-had/jboss approach for implementing a OSGI like class loading engine.
So to the me the whole module syntax detailing what to export, what to import from a given module felt like a possible OSGI implementation.
This may not be correct on my side.
But to a certain extend it does feel like that in any case the architecture of the module system of wildfly is supposed to be able to cope with the different jar files versions for the same type of implementation (e.g. multiple modules of log4j) if each module is properly isolated for another.
But ultimately this why I called osgi.
I am sorry if this has created confusion.
Many thanks.
was (Author: nuno.godinhomatos):
Hi James, I am using the pure wildly class loading mechanism. I incorrectly called OSGI, because to me the class-loading module mechanism looked like a red-had/jboss approach for implementing a OSGI like class loading engine.
So to the me the whole module syntax detailing what to export, what to import from a given module felt like a OSGI implementation.
I see that this is incorrect on my side.
But to a certain extend it does feel like that in any case the architecture of the module system of wildfly is supposed to be able to cope with the different jar files versions for the same type of implementation (e.g. multiple modules of log4j) if each module is properly isolated for another.
But ultimately this why I called osgi.
I am sorry if this has created confusion.
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)
8 years, 3 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3210:
----------------------------------
Summary: Wildfly module isolation not working consistently (was: Wildfly osgi/module isolation not working consistently)
> 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 OSGI subsystem, 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)
8 years, 3 months
[JBoss JIRA] (WFCORE-3210) Wildfly osgi/module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos commented on WFCORE-3210:
-----------------------------------------------
Hi James, I am using the pure wildly class loading mechanism. I incorrectly called OSGI, because to me the class-loading module mechanism looked like a red-had/jboss approach for implementing a OSGI like class loading engine.
So to the me the whole module syntax detailing what to export, what to import from a given module felt like a OSGI implementation.
I see that this is incorrect on my side.
But to a certain extend it does feel like that in any case the architecture of the module system of wildfly is supposed to be able to cope with the different jar files versions for the same type of implementation (e.g. multiple modules of log4j) if each module is properly isolated for another.
But ultimately this why I called osgi.
I am sorry if this has created confusion.
Many thanks.
> Wildfly osgi/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 OSGI subsystem, 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)
8 years, 3 months