I need to implement detailed logging within my OSB message flows. Some of the EJBs in the domain are already using log4j2, and I'd like to use a Java Callout to leverage the same log file and configuration. I've written my Java Callout, added calls to it from my OSB message flow, and added a logger for my class in the existing log4j2 config XML.
The EJBs that are already using log4j for logging include the three log4j 2.3 JARs in their EAR. My callout can't see these, so I've placed copies of the log4j JARs in my %DOMAIN_HOME%/lib directory. With this arrangement, I'm seeing entries appear in the log file, as intended; but there's a problem. Fusion Middleware Control will no longer respond, and a search of the AdminServer log reveals what appears to be a conflict between some log4j class it wants to use and the ones I've placed in %DOMAIN_HOME%/lib:
<Nov 15, 2016 12:18:20 PM CST> <Error> <Deployer> <BEA-149231> <Unable to set the activation state to true for the application "em".
weblogic.application.ModuleException: java.lang.NoSuchMethodError: org.apache.log4j.PatternLayout: method <init>()V not found
at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:140)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:237)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:232)
at weblogic.application.utils.StateMachineDriver$ParallelChange.run(StateMachineDriver.java:83)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NoSuchMethodError: org.apache.log4j.PatternLayout: method <init>()V not found
at oracle.sysman.util.logging.JavaSdkLogOperations.addNullHandlertoLog4j(JavaSdkLogOperations.java:854)
at oracle.sysman.util.logging.JavaSdkLogOperations.setDefaultEmRootConfiguration(JavaSdkLogOperations.java:882)
at oracle.sysman.util.logging.JavaSdkLogOperations.initLoggingSystem(JavaSdkLogOperations.java:424)
at oracle.sysman.util.logging.DualModeLogOperations.initLoggingSystem(DualModeLogOperations.java:424)
at oracle.sysman.emSDK.util.logging.Logger._init(Logger.java:2015)
Truncated. see log file for complete stacktrace
>
In a effort to correct this, I moved the log4j JARs to another directory and appended the classpath in the setDomainEnv startup script. I tried using both PRE_CLASSPATH and POST_CLASSPATH (not at the same time), but both cases broke some dependency that caused the following errors to be logged repeatedly:
2016-11-15 09:35:06,670 (ClassUtils) [DEBUG] - Class [edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap] or one of its dependencies is not present: java.lang.ClassNotFoundException: edu.emory.mathcs.backport.java.util.concurrent.ConcurrentHashMap
2016-11-15 09:35:06,676 (CollectionFactory) [DEBUG] - Falling back to plain synchronized [java.util.HashMap] for concurrent map
[REPEATS x8]
2016-11-15 09:35:06,757 (GenericApplicationContext) [INFO ] - Refreshing com.bea.core.repackaged.springframework.context.support.GenericApplicationContext@2be9ab02: display name [com.bea.core.repackaged.springframework.context.support.GenericApplicationContext@2be9ab02]; startup date [Tue Nov 15 09:35:06 CST 2016]; root of context hierarchy
2016-11-15 09:35:06,757 (GenericApplicationContext) [INFO ] - Bean factory for application context [com.bea.core.repackaged.springframework.context.support.GenericApplicationContext@2be9ab02]: com.bea.core.repackaged.springframework.beans.factory.support.DefaultListableBeanFactory@1149e0d0
2016-11-15 09:35:06,758 (GenericApplicationContext) [DEBUG] - 1 beans defined in com.bea.core.repackaged.springframework.context.support.GenericApplicationContext@2be9ab02: display name [com.bea.core.repackaged.springframework.context.support.GenericApplicationContext@2be9ab02]; startup date [Tue Nov 15 09:35:06 CST 2016]; root of context hierarchy
2016-11-15 09:35:06,766 (DefaultListableBeanFactory) [DEBUG] - Creating shared instance of singleton bean 'com.oracle.pitchfork.intercept.InterceptionMetadataBeanPostProcessor'
2016-11-15 09:35:06,767 (DefaultListableBeanFactory) [DEBUG] - Creating instance of bean 'com.oracle.pitchfork.intercept.InterceptionMetadataBeanPostProcessor'
2016-11-15 09:35:06,781 (DefaultListableBeanFactory) [DEBUG] - Eagerly caching bean 'com.oracle.pitchfork.intercept.InterceptionMetadataBeanPostProcessor' to allow for resolving potential circular references
2016-11-15 09:35:06,782 (DefaultListableBeanFactory) [DEBUG] - Finished creating instance of bean 'com.oracle.pitchfork.intercept.InterceptionMetadataBeanPostProcessor'
2016-11-15 09:35:06,783 (GenericApplicationContext) [DEBUG] - Unable to locate MessageSource with name 'messageSource': using default [com.bea.core.repackaged.springframework.context.support.DelegatingMessageSource@2513d2ca]
2016-11-15 09:35:06,784 (GenericApplicationContext) [DEBUG] - Unable to locate ApplicationEventMulticaster with name 'applicationEventMulticaster': using default [com.bea.core.repackaged.springframework.context.event.SimpleApplicationEventMulticaster@1ac914da]
2016-11-15 09:35:06,785 (DefaultListableBeanFactory) [INFO ] - Pre-instantiating singletons in com.bea.core.repackaged.springframework.beans.factory.support.DefaultListableBeanFactory@1149e0d0: defining beans [com.oracle.pitchfork.intercept.InterceptionMetadataBeanPostProcessor]; root of factory hierarchy
2016-11-15 09:35:06,785 (DefaultListableBeanFactory) [DEBUG] - Returning cached instance of singleton bean 'com.oracle.pitchfork.intercept.InterceptionMetadataBeanPostProcessor'
2016-11-15 09:35:06,786 (GenericApplicationContext) [DEBUG] - Publishing event in context [com.bea.core.repackaged.springframework.context.support.GenericApplicationContext@2be9ab02]: com.bea.core.repackaged.springframework.context.event.ContextRefreshedEvent[source=com.bea.core.repackaged.springframework.context.support.GenericApplicationContext@2be9ab02: display name [com.bea.core.repackaged.springframework.context.support.GenericApplicationContext@2be9ab02]; startup date [Tue Nov 15 09:35:06 CST 2016]; root of context hierarchy]
I know that setting the classpath for the OSB is possible via the Server Startup tab in the admin console, but this seems to replace the classpath with whatever is entered, rather than appending to it. So that's no good.
Short of changing the EJBs to use one of the older versions of log4j that appear in the weblogic modules directory, can anyone suggest a way set up the environment so that my Java Callout can find the log4j2 JARs, while at the same time not breaking Enterprise Manager or what appears to be some sort of Spring dependency? Is there some way to package the required log4j2 JARs along with the Java callout JAR, in my OSB JAR?
Thanks,
Alan