static initialization in Java EE differs between parentfirst/parentlast classloading policy, at least in Websphere Liberty -
i discovered interesting, may wrong behaviour in websphere liberty / jee 7, discuss if bug or feature.
first, code described older project have taken over, , code not fanciest or best way something. let's point: there utility-jar, contains servletcontextlistener. listener performs log4j initialization way, has final static variable causes log4j initialization, when class loaded first time.
the maven build produces 2 wars, each war contains utility-jar containing servletcontextlistener. see following graphic in order see structure of ear:
this means have 2 webapps containing same utility-jar, contains static initilizer this:
private static final mylogger log = logger.getlogger("webapp-1"); and here point: when deploy on liberty standard classloader policy (parentfirst), static initialization takes place 1 time! when using parentlast policy, static initialization hapens 2 times.
i have discussed colleague first said, that's ok. thinking of more , more, we came mind behaviour wrong. there no way, webapp-1 finding class part of webapp-2 or vice versa. that's why static initialization (i.e. classloading) must occure each webapp separately. no matter classloading policy, because liberty not have log4j.jar on own.
so, heck has classloader policy that? in oppinion should have nothing that.
what think? bug in liberty, design/intend (explanation, please) or it?
please note, not looking solution, there plenty. interested, how other developers think on topic.
the issue seems affect static members of classes. because log4j initialization static, matter of log4j initializing each webapp or initializing once (the webapp loaded first).
you can check this, using utility class separate jar, has static member initialized statically. parentfirst policy, initialized 1 time. , should not be, afai understand.
********** addition, inspired 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 different. question is, correct? don't think so, think flaw.
Comments
Post a Comment