I discovered an interesting, may be wrong behaviour in Websphere Liberty / JEE 7, which I like to discuss if this is a bug or a feature.
First, the code described is an older Project which I have taken over, and the code is not always the fanciest or best way to do something. So let's get to the point: There is a utility-jar, which contains a ServletContextListener. The Listener performs the log4j initialization that way, that it has a final static variable that causes log4j initialization, when the class is loaded the first time.
The maven build produces two WARs, where each WAR contains the utility-jar containing the ServletContextListener. See the following graphic in order to see the structure of the EAR:
This means I have two webapps containing the same utility-jar, which contains a static initilizer like this:
private static final MyLogger LOG = Logger.getLogger("webapp-1");
And here is my point: When I deploy it on Liberty with standard classloader policy (parentfirst), that static initialization takes place only ONE TIME! When using parentLast Policy, static initialization hapens TWO TIMES.
I have discussed this with a colleague who first said, that's OK. But thinking of it more and more, we came to mind that this behaviour is actually wrong. There is no way, where webapp-1 is finding any class which is part of webapp-2 or vice versa. That's why the static initialization (i.e. Classloading) must occure for each webapp separately. No matter which classloading policy, because Liberty does not have a log4j.jar on its Own.
So, what the heck has the classloader policy to do with that? In my oppinion it should have nothing to do with that.
What do you think? Is it a bug in Liberty, is it by design/intend (explanation, please) or what is it?
Please note, I am not looking for a solution, there are plenty. I am just interested, how other developers think on this topic.
The issue seems to affect only static members of classes. Because the log4j initialization is static, it is a matter of log4j is initializing for each webapp or initializing only once (the webapp which is loaded first).
You can check this, by using a utility class from a separate jar, which has a static member which is initialized statically. With parentFirst policy, it will be initialized only one time. And this should not be, afai understand.
********** Addition, inspired by Andy McWright *****
parentFirst:
[25.07.17 15:24:39:405 MESZ] 00000063 id=40ad88b3 lassloading.internal.ContainerClassLoader$SmartClassPathImpl > getUniversalContainersForPath Entry
[user.dir].m2\repository\log4j\log4j\1.2.17\log4j-1.2.17.jar
[25.07.17 15:25:02:880 MESZ] 00000063 id=0f48e3d8 com.ibm.ws.classloading.internal.AppClassLoader > findOrDelegateLoadClass Entry
org.apache.log4j.Logger
parentLast:
[25.07.17 15:46:38:580 MESZ] 00000064 id=1d3c9ea4 lassloading.internal.ContainerClassLoader$SmartClassPathImpl > getUniversalContainersForPath Entry
[user.dir].m2\repository\log4j\log4j\1.2.17\log4j-1.2.17.jar,
[25.07.17 15:46:20:471 MESZ] 00000064 id=70f6cf68 com.ibm.ws.classloading.internal.ParentLastClassLoader > loadClass Entry
org.apache.log4j.Logger
[25.07.17 15:46:20:471 MESZ] 00000064 id=70f6cf68 com.ibm.ws.classloading.internal.AppClassLoader > findClass Entry
org.apache.log4j.Logger
[25.07.17 15:46:20:471 MESZ] 00000064 id=70f6cf68 com.ibm.ws.classloading.internal.AppClassLoader > findClassBytes Entry
org.apache.log4j.Logger
[25.07.17 15:46:20:471 MESZ] 00000064 id=70f6cf68 com.ibm.ws.classloading.internal.ContainerClassLoader > findBytes Entry
org/apache/log4j/Logger.class
[25.07.17 15:46:20:471 MESZ] 00000064 id=1d3c9ea4 lassloading.internal.ContainerClassLoader$SmartClassPathImpl > getByteResourceInformation Entry
org/apache/log4j/Logger.class
[25.07.17 15:46:20:471 MESZ] 00000064 id=1d3c9ea4 lassloading.internal.ContainerClassLoader$SmartClassPathImpl > getUniversalContainersForPath Entry
org/apache/log4j/Logger.class
Yes, Classloading is different. The question is, is this correct? I don't think so, I think it is a flaw.