[jira] [Commented] (LOG4J2-2124) Cannot deploy application that contains Log4j 2.9.x to weblogic server due to com.objectweb.asm.ClassReader errors
[
https://issues-test.apache.org/jira/browse/LOG4J2-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265602#comment-16265602
]
Jonathan Garzón Peña commented on LOG4J2-2124:
--
I had the same problem, It think the issue is because the java version is
wrong, I had the problem with a WebLogic 12.1.3, which is configured with java
7 and with some misconfigurations. You should review your weblogic settings and
the jdk version which you use.
Finally, I had to use the log4j-2.8.2 library, but if you use slf4j binding,
you should be sure that the weblogic-application.xml or weblogic-web.xml files
define to use slf4j.
> Cannot deploy application that contains Log4j 2.9.x to weblogic server due to
> com.objectweb.asm.ClassReader errors
> --
>
> Key: LOG4J2-2124
> URL: https://issues-test.apache.org/jira/browse/LOG4J2-2124
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.0, 2.9.1
> Environment: Linux weblogic server 12.1.3
>Reporter: Simon Billingsley
>Priority: Major
>
> When trying to deploy an application that contains log4j 2.9.0 or 2.9.1 to a
> weblogic 12.1.3 server I get the following deployment exceptions and the
> deployment fails.
> Looking at the stacktrace it seems that it has something to do with
> com.objectweb.asm which is repackaged as com.bea.objectweb.asm in the
> following library: asm-3.1.jar which is part of the core weblogic platform.
> Reverting back to log4j 2.8.2 fixes the issue and allows the application to
> be deployed.
> I have looked through the changes that were introduced in log4j 2.9.x and I
> think it could have something to do with jdk 9 multi-release support. Could
> it be that the old asm is having problems parsing the jdk 9 compiled classes
> contained within log4j ?
> {noformat}
> <1511345766104> task for application "app".>
>
> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default
> (self-tuning)'> <> <> <>
> <1511345766104> weblogic.application.ModuleException: null
> null
> at
> weblogic.servlet.internal.WebAppModule.createModuleException(WebAppModule.java:1824)
> at weblogic.servlet.internal.WebAppModule.init(WebAppModule.java:270)
> at weblogic.servlet.internal.WebAppModule.init(WebAppModule.java:682)
> at
> weblogic.application.internal.flow.ScopedModuleDriver.init(ScopedModuleDriver.java:162)
> at
> weblogic.application.internal.ExtensibleModuleWrapper.init(ExtensibleModuleWrapper.java:98)
> at
> weblogic.application.internal.flow.ModuleListenerInvoker.init(ModuleListenerInvoker.java:84)
> at
> weblogic.application.internal.flow.InitModulesFlow.initModule(InitModulesFlow.java:288)
> at
> weblogic.application.internal.flow.InitModulesFlow.initModules(InitModulesFlow.java:301)
> at
> weblogic.application.internal.flow.InitModulesFlow.prepare(InitModulesFlow.java:329)
> at
> weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:706)
> at
> weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
> at
> weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:237)
> at
> weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:61)
> at
> weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158)
> at
> weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:61)
> at
> weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:208)
> at
> weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98)
> at
> weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:233)
> at
> weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:749)
> at
> weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1238)
> at
> weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:252)
> at
> weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:172)
> at
> weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171)
> at
> weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13)
> at
>
[jira] [Updated] (LOG4NET-589) Impossible to use ProcessExit event for logging needs
[ https://issues.apache.org/jira/browse/LOG4NET-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Serbin updated LOG4NET-589: - Attachment: LoggerManager.cs > Impossible to use ProcessExit event for logging needs > - > > Key: LOG4NET-589 > URL: https://issues.apache.org/jira/browse/LOG4NET-589 > Project: Log4net > Issue Type: Improvement > Components: Core >Reporter: Aleksandr Serbin >Priority: Minor > Attachments: log4net_nonworking.cs, log4net_working.cs > > > LoggerManager use ProcessExit event to run shutdown on each > repository/loggers. If the user wants to use these events (ProcessExit or > DomainUnload) also to log own data, he will meet the problem, since > LoggerManager will shutdown all loggers first (log4net_nonworking.cs). > There is a workaround when you can initialize logger in main method (showed > in log4net_working.cs), but then all code loses readability. > > * It would be great if LoggerManager won't use ProcessExit and DomainUnload > to shutdown loggers, since this event might be used in user application for > own needs. > * If you can not refuse these events, then it would be good to have a public > method to reregister those events. User will add own delegates first and then > reregister LoggerManager events. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (LOG4NET-589) Impossible to use ProcessExit event for logging needs
[ https://issues.apache.org/jira/browse/LOG4NET-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Serbin updated LOG4NET-589: - Attachment: (was: LoggerManager.cs) > Impossible to use ProcessExit event for logging needs > - > > Key: LOG4NET-589 > URL: https://issues.apache.org/jira/browse/LOG4NET-589 > Project: Log4net > Issue Type: Improvement > Components: Core >Reporter: Aleksandr Serbin >Priority: Minor > Attachments: log4net_nonworking.cs, log4net_working.cs > > > LoggerManager use ProcessExit event to run shutdown on each > repository/loggers. If the user wants to use these events (ProcessExit or > DomainUnload) also to log own data, he will meet the problem, since > LoggerManager will shutdown all loggers first (log4net_nonworking.cs). > There is a workaround when you can initialize logger in main method (showed > in log4net_working.cs), but then all code loses readability. > > * It would be great if LoggerManager won't use ProcessExit and DomainUnload > to shutdown loggers, since this event might be used in user application for > own needs. > * If you can not refuse these events, then it would be good to have a public > method to reregister those events. User will add own delegates first and then > reregister LoggerManager events. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LOG4NET-589) Impossible to use ProcessExit event for logging needs
[ https://issues.apache.org/jira/browse/LOG4NET-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16358964#comment-16358964 ] Aleksandr Serbin commented on LOG4NET-589: -- [^LoggerManager.cs] Attached an example of a patch. In the patch removed the use of the AppDomain.DomainUnload and AppDomain.ProcessExit event. Instead added private internal sealed Destructor class which define destructor that call Shutdown function. > Impossible to use ProcessExit event for logging needs > - > > Key: LOG4NET-589 > URL: https://issues.apache.org/jira/browse/LOG4NET-589 > Project: Log4net > Issue Type: Improvement > Components: Core >Reporter: Aleksandr Serbin >Priority: Minor > Attachments: LoggerManager.cs, log4net_nonworking.cs, > log4net_working.cs > > > LoggerManager use ProcessExit event to run shutdown on each > repository/loggers. If the user wants to use these events (ProcessExit or > DomainUnload) also to log own data, he will meet the problem, since > LoggerManager will shutdown all loggers first (log4net_nonworking.cs). > There is a workaround when you can initialize logger in main method (showed > in log4net_working.cs), but then all code loses readability. > > * It would be great if LoggerManager won't use ProcessExit and DomainUnload > to shutdown loggers, since this event might be used in user application for > own needs. > * If you can not refuse these events, then it would be good to have a public > method to reregister those events. User will add own delegates first and then > reregister LoggerManager events. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
