August 2017 - jboss-jira - Jboss List Archives

[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. Thank you so much. I will try to give you tomorrow a pacakage with a Module oour Jul Router i was told this is eine. And a Basic Domain. Theb when i believe you need to play With Start via Script vs via Eclipse. That is how i am able to make it fail. And probabaly a critical Element is that my Module for Jul Routing needs Access to Just One class of the core logmanager Module. The ext logrecord for Jul. So the Module i have for Routing triew to Import Just this One class from org.jboss.logmanager. and i believe the key to the phenomena must be there... I will give you the pacakage tomorrow. Many thanks. 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)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) EJB client(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9275?page=com.atlassian.jira.plugin.... ] Loren Chang updated WFLY-9275: ------------------------------ Description: This test code on "public static void main" is ok, but fail on war/ear EJB client API Version:wildfly-naming-client-1.0.0.Beta13.jar、jboss-remote-naming-2.0.4.Final.jar was: This test code on "public static void main" is ok, but fail on war/ear naming > EJB client(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-9275 > URL: https://issues.jboss.org/browse/WFLY-9275 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Loren Chang > Attachments: WildFlyBug.png > > > This test code on "public static void main" is ok, but fail on war/ear > EJB client API Version:wildfly-naming-client-1.0.0.Beta13.jar、jboss-remote-naming-2.0.4.Final.jar -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) EJB client(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9275?page=com.atlassian.jira.plugin.... ] Loren Chang updated WFLY-9275: ------------------------------ Summary: EJB client(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) (was: naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)) > EJB client(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-9275 > URL: https://issues.jboss.org/browse/WFLY-9275 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Loren Chang > Attachments: WildFlyBug.png > > > This test code on "public static void main" is ok, but fail on war/ear > naming -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9275?page=com.atlassian.jira.plugin.... ] Loren Chang updated WFLY-9275: ------------------------------ Description: This test code on "public static void main" is ok, but fail on war/ear naming was:This test code on "public static void main" is ok, but fail on war/ear > naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9275 > URL: https://issues.jboss.org/browse/WFLY-9275 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Loren Chang > Attachments: WildFlyBug.png > > > This test code on "public static void main" is ok, but fail on war/ear > naming -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9275?page=com.atlassian.jira.plugin.... ] Loren Chang updated WFLY-9275: ------------------------------ Summary: naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) (was: wildfly naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)) > naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9275 > URL: https://issues.jboss.org/browse/WFLY-9275 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Loren Chang > Attachments: WildFlyBug.png > > > This test code on "public static void main" is ok, but fail on war/ear -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) wildfly naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9275?page=com.atlassian.jira.plugin.... ] Loren Chang updated WFLY-9275: ------------------------------ Description: This test code on "public static void main" is ok, but fail on war/ear > wildfly naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9275 > URL: https://issues.jboss.org/browse/WFLY-9275 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Loren Chang > Attachments: WildFlyBug.png > > > This test code on "public static void main" is ok, but fail on war/ear -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9275) wildfly naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client)

by Loren Chang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9275?page=com.atlassian.jira.plugin.... ] Loren Chang updated WFLY-9275: ------------------------------ Attachment: WildFlyBug.png > wildfly naming api(on ear/war) lookup remote SessionBean on multi server fail, all request recieved by one server(client) > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-9275 > URL: https://issues.jboss.org/browse/WFLY-9275 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Loren Chang > Attachments: WildFlyBug.png > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[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: --------------------------------------- I created a very simple test appender and a JUL handler to appender class. I installed a separate log4j module, installed the module and created a custom handler resource. It all seemed to work fine for me. I'm not sure what the issue could be. > 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

1
0
0 / 0

[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: ----------------------------------------------- And answer your final question. I do not know how I can make myself any clearer. No we have absolutely no intention of having log4j configuration per deployment. Not at all. No war, or ear we produce will ever contain a lo4j property configuration. We configure the logging at the logging subsytem leveling such a way that all applications deployed are using the one and only global configuration. Deployed applications limit themselves to use logging APIs. The logging goes to the wildfly logmanager. The logmanager calls our jul to log4j der. And our jul to log4j appender calls the pure log4j implementation that is configured just the way we want it with the appenders we like and have implemented. I hope this description is clear. And I hope as well that you do not tell me that I am trying to do is not possible because with my limited internal knowledge of wildly I can already that what I am trying to do is definitely possible based on the module architecture. 100 % possible. It just requires one simple trivial elements to be in place. And that is the module of our jul to log4j apprentder to be isolated from the jboss log4j implementation. And this simply has to be possible. I cannot believe for one second that this is not supposed to be possible. > 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

1
0
0 / 0

[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, I think what I am doing should be clear by the module configuration I have presented. What is not clear about my explanation? The wildfly logging subsystem routes log4j events to Jboss log manager. I have a JuL handler that routes jul logging events to log4j. The log4j implementation I need to use is the pure log4j implementation that is not tweaked to try to route to the log manager. And finally I believe there is no error on my behalf when I state that the wildfly module subsytemevents designed to be able to cope with class isolation and defines an XML definition scheme that provides imports and exports and excludes attributes precisely for this effect. There is also no error on my part when I say that the module architecture of wildfly should be able to cope with what I am doing. Please explain to me what does it matter that wildfly has its own tweaked log4j implementation and i create a module with the pure untouched log4j configuration? What does it matter if the class loader formymodule is properly isolated, it should simply not be possiblethat my JUL handler even feels the presence of the log4j classes Inthe boss log4j. Formymodule handler ifitproperly isolated the jboss log4j classses should simply not exist. There is no race condition in this scenario. No race condition I say again . A race condition exists ifimake aWAr file that bundles two versions of the same library ora version of a library provided by the container and Ido not ask for isolation. This is abundantly clear that it is not what is happening here. If a race condition is taking place then it is clear the module isolation is not preventing my module from being safe promthejboss log4j module when it should. By design my module should have no race condition of it properly isolated? Why is this so hard to understand? > 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

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2017