4:09 a.m.
[
https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi...
]
Nuno Godinho de Matos commented on WFCORE-3210:
-----------------------------------------------
Hi James,
I would like to share with you the following google drive reference:
[#https://drive.google.com/drive/folders/0B_dEiNBGUsxqRW1oQkg2LXUyZms?usp=sharing]
In this driver folder you will have two artifacts.
01_wildfly_module_company.zip
02_standalone-WFCORE3210.zip
The first zip file contains a wildfly module, text logs from me switching around starting
a wildfly domain via script and via eclipse. And illustrating that when i do the switch
between how I startup wildfly the issue with class loading sneaks in. then when I keep
starting wildfly with the same apporach either batch file or eclipse the issue stops
manifesting.
This module is identical to what you have on a previous entry on this jira.
The difference is that the module stops referring to the Appenders jar file and just holds
the pure log4j implementation and the router module.
You also have the source code for the router module in there.
To install this module, go to you WILDFLY_HOME/modules/ and simply dump the module in
there.
You should have in your file system a path of the form:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\modules\company\logginglog4j1\main
The second artifact is a domain.
On this domain you have an additional bin/ folder with scripts that you can use to start
the wildfly domain.
Just make sure that when you copy the doman, you do not put it in WILDFLY_HOME.
Instead you need to make a deeper folder hiearchy as illustrated by this path:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210
That is it.
On my environment: Windows 7.
The phenomena I experience is that normally, when I start the domain for a first time with
an approach A.
The starting up has problems with the logging classes.
When I stop the domain and keep using the approach A to start the domain I am fine and
the:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210\log
WFCORE3210_rollingFileAppender.log
Is getting pumped up with all the application server events.
Which is the ideal thing.
Then, If I swtich my startup approach form A to B, e.g. from bat to eclpse.
The issue manifests once, and then I am fine again.
Last note.
You will want to fix the file:
C:\dev\appserver\wildfly\wildfly-10.1.0.Final\user_projects\domains\standalone-WFCORE3210\configuration\log4jwildfly.properties
The rolling file appender configured in there has a destination directory that is ok for
my folder structure, but which will not be ok for your folder structure, since I doubt you
are either using widows or putting your wildfly home where I put mine.
Many thanks for your help,
I hope this package allows you to reproduce the issue,
Kindest regards.
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)
2675
days inactive
2675
days old
0 comments
1 participants
participants (1)
-
Nuno Godinho de Matos (JIRA)