[jira] [Created] (LOG4J2-612) RollingFileAppender does not reuse PatternParser
Jan Stolze created LOG4J2-612: - Summary: RollingFileAppender does not reuse PatternParser Key: LOG4J2-612 URL: https://issues.apache.org/jira/browse/LOG4J2-612 Project: Log4j 2 Issue Type: Bug Affects Versions: 2.0-rc1 Reporter: Jan Stolze Creating a RollingFileAppender leads to creation of a RollingFileManager which creates a PatternProcessor, which creates a PatternParser. The PatternParser will start out a plugin find expedition on the classpath which takes some time. This is done for every RollingFileAppender you create. In my case the log file naming pattern is always the same for all log files, so I do not see the necessity for this plugin finding expedition. For instance PatternLayout does not do this as long as you supply a Configuration object which reuses the PatternParser for this Configuration object. Can RollingFileManager follow the same pattern as PatternLayout does? -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-461) ERROR StatusLogger Unable to locate a logging implementation, using SimpleLogger
[
https://issues.apache.org/jira/browse/LOG4J2-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979390#comment-13979390
]
Abid commented on LOG4J2-461:
-
Hi,
I am also hitting the same ClassCastException issue while trying to run the
log4j2 in WebLogic application server. Here is what I have done:
- if I put the api and core jars into DOMAIN_HOME/lib (equivalent to adding the
jars into server classpath) things run okay.
- if I put the api and core jars into
WL_HOME/server/lib/mbeantypes/3rdpartyjars, then this classcast exception is
thrown:
java.lang.ClassCastException:
org.apache.logging.log4j.simple.SimpleLoggerContext
at
com.qnb.itd.wls.sec.providers.QNBAuditProviderImpl.initialize(QNBAuditProviderImpl.java:108)
at
com.bea.common.security.internal.legacy.service.SecurityProviderImpl.init(SecurityProviderImpl.java:65)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:363)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:315)
at
com.bea.common.engine.internal.ServiceEngineImpl.lookupService(ServiceEngineImpl.java:257)
at
com.bea.common.engine.internal.ServicesImpl.getService(ServicesImpl.java:72)
at
weblogic.security.service.internal.WLSIdentityServiceImpl.initialize(Unknown
Source)
at
weblogic.security.service.CSSWLSDelegateImpl.initializeServiceEngine(Unknown
Source)
at weblogic.security.service.CSSWLSDelegateImpl.initialize(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.InitializeServiceEngine(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initializeRealm(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.loadRealm(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initializeRealms(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initialize(Unknown
Source)
at weblogic.security.service.SecurityServiceManager.initialize(Unknown
Source)
at weblogic.security.SecurityService.start(SecurityService.java:141)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
With code snippet:
import org.apache.logging.log4j.core.LoggerContext;
import org.apache.logging.log4j.LogManager;
...
...
public final class MyAuditProviderImpl implements AuditProvider, AuditChannel{
...
...
public void initialize(ProviderMBean mbean, SecurityServices services){
...
...
LoggerContext ctx = null;
Configuration config = null;
Map mp = null;
ctx = (LoggerContext) LogManager.getContext(false);
mp = config.getAppenders();
System.out.println(***MyAudit Provider o/p follows Before logger
re-configuration:);
System.out.println(\tAppenders: + mp.keySet());
...
...
}
}
- with least hope to solve this issue, I also merged the two jars carefully
(making sure MANIFEST.MF has all the entries) into single one but still same
issue.
Hope this helps in someway to identify what is going wrong.
I am ready to test to collect any additional data for debugging.
Thanks
ERROR StatusLogger Unable to locate a logging implementation, using
SimpleLogger
-
Key: LOG4J2-461
URL: https://issues.apache.org/jira/browse/LOG4J2-461
Project: Log4j 2
Issue Type: Bug
Components: API
Affects Versions: 2.0-beta9
Environment: Android
Reporter: Gaurav Kapoor
Priority: Blocker
ERROR StatusLogger Unable to locate a logging implementation, using
SimpleLogger
Code:
Logger LOG = LogManager.getLogger(MainActivity.class);
LOG.error(Test Log4j2);
{code}
?xml version=1.0 encoding=UTF-8?
Configuration
Appenders
Console name=STDOUT target=SYSTEM_OUT
PatternLayout pattern=%d %-5p [%t] %C{2} (%F:%L) - %m%n/
/Console
/Appenders
Loggers
Logger name=hello level=info/
Root level=trace
AppenderRef ref=STDOUT/
/Root
/Loggers
/Configuration
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Updated] (LOG4J2-461) ERROR StatusLogger Unable to locate a logging implementation, using SimpleLogger
[
https://issues.apache.org/jira/browse/LOG4J2-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abid updated LOG4J2-461:
Attachment: MANIFEST.MF
ERROR StatusLogger Unable to locate a logging implementation, using
SimpleLogger
-
Key: LOG4J2-461
URL: https://issues.apache.org/jira/browse/LOG4J2-461
Project: Log4j 2
Issue Type: Bug
Components: API
Affects Versions: 2.0-beta9
Environment: Android
Reporter: Gaurav Kapoor
Priority: Blocker
Attachments: MANIFEST.MF
ERROR StatusLogger Unable to locate a logging implementation, using
SimpleLogger
Code:
Logger LOG = LogManager.getLogger(MainActivity.class);
LOG.error(Test Log4j2);
{code}
?xml version=1.0 encoding=UTF-8?
Configuration
Appenders
Console name=STDOUT target=SYSTEM_OUT
PatternLayout pattern=%d %-5p [%t] %C{2} (%F:%L) - %m%n/
/Console
/Appenders
Loggers
Logger name=hello level=info/
Root level=trace
AppenderRef ref=STDOUT/
/Root
/Loggers
/Configuration
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-461) ERROR StatusLogger Unable to locate a logging implementation, using SimpleLogger
[
https://issues.apache.org/jira/browse/LOG4J2-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979390#comment-13979390
]
Abid edited comment on LOG4J2-461 at 4/24/14 7:28 AM:
--
Hi,
I am also hitting the same ClassCastException issue while trying to run the
log4j2 in WebLogic application server. Here is what I have done:
- if I put the api and core jars into DOMAIN_HOME/lib (equivalent to adding the
jars into server classpath) things run okay.
- if I put the api and core jars into
WL_HOME/server/lib/mbeantypes/3rdpartyjars, then this classcast exception is
thrown:
java.lang.ClassCastException:
org.apache.logging.log4j.simple.SimpleLoggerContext
at
com.qnb.itd.wls.sec.providers.QNBAuditProviderImpl.initialize(QNBAuditProviderImpl.java:108)
at
com.bea.common.security.internal.legacy.service.SecurityProviderImpl.init(SecurityProviderImpl.java:65)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:363)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:315)
at
com.bea.common.engine.internal.ServiceEngineImpl.lookupService(ServiceEngineImpl.java:257)
at
com.bea.common.engine.internal.ServicesImpl.getService(ServicesImpl.java:72)
at
weblogic.security.service.internal.WLSIdentityServiceImpl.initialize(Unknown
Source)
at
weblogic.security.service.CSSWLSDelegateImpl.initializeServiceEngine(Unknown
Source)
at weblogic.security.service.CSSWLSDelegateImpl.initialize(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.InitializeServiceEngine(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initializeRealm(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.loadRealm(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initializeRealms(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initialize(Unknown
Source)
at weblogic.security.service.SecurityServiceManager.initialize(Unknown
Source)
at weblogic.security.SecurityService.start(SecurityService.java:141)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
With code snippet:
===starts==
import org.apache.logging.log4j.core.LoggerContext;
import org.apache.logging.log4j.LogManager;
...
...
public final class MyAuditProviderImpl implements AuditProvider, AuditChannel{
...
...
public void initialize(ProviderMBean mbean, SecurityServices services){
...
...
LoggerContext ctx = null;
Configuration config = null;
Map mp = null;
ctx = (LoggerContext) LogManager.getContext(false);
mp = config.getAppenders();
System.out.println(***MyAudit Provider o/p follows Before logger
re-configuration:);
System.out.println(\tAppenders: + mp.keySet());
...
...
}
}
===ends==
- with least hope to solve this issue, I also merged the two jars carefully
(making sure MANIFEST.MF has all the entries) into single one but still same
issue.
Hope this helps in someway to identify what is going wrong.
I am ready to test to collect any additional data for debugging.
Thanks
was (Author: pirabid):
Hi,
I am also hitting the same ClassCastException issue while trying to run the
log4j2 in WebLogic application server. Here is what I have done:
- if I put the api and core jars into DOMAIN_HOME/lib (equivalent to adding the
jars into server classpath) things run okay.
- if I put the api and core jars into
WL_HOME/server/lib/mbeantypes/3rdpartyjars, then this classcast exception is
thrown:
java.lang.ClassCastException:
org.apache.logging.log4j.simple.SimpleLoggerContext
at
com.qnb.itd.wls.sec.providers.QNBAuditProviderImpl.initialize(QNBAuditProviderImpl.java:108)
at
com.bea.common.security.internal.legacy.service.SecurityProviderImpl.init(SecurityProviderImpl.java:65)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:363)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:315)
at
com.bea.common.engine.internal.ServiceEngineImpl.lookupService(ServiceEngineImpl.java:257)
at
com.bea.common.engine.internal.ServicesImpl.getService(ServicesImpl.java:72)
at
weblogic.security.service.internal.WLSIdentityServiceImpl.initialize(Unknown
Source)
at
[jira] [Comment Edited] (LOG4J2-461) ERROR StatusLogger Unable to locate a logging implementation, using SimpleLogger
[
https://issues.apache.org/jira/browse/LOG4J2-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979390#comment-13979390
]
Abid edited comment on LOG4J2-461 at 4/24/14 7:32 AM:
--
Hi,
I am also hitting the same ClassCastException issue while trying to run the
log4j2 in WebLogic application server. Here is what I have done:
- if I put the api and core jars into DOMAIN_HOME/lib (equivalent to adding the
jars into server classpath) things run okay.
- if I put the api and core jars into
WL_HOME/server/lib/mbeantypes/3rdpartyjars, then this classcast exception is
thrown:
java.lang.ClassCastException:
org.apache.logging.log4j.simple.SimpleLoggerContext
at
com.qnb.itd.wls.sec.providers.MyAuditProviderImpl.initialize(QNBAuditProviderImpl.java:108)
at
com.bea.common.security.internal.legacy.service.SecurityProviderImpl.init(SecurityProviderImpl.java:65)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:363)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:315)
at
com.bea.common.engine.internal.ServiceEngineImpl.lookupService(ServiceEngineImpl.java:257)
at
com.bea.common.engine.internal.ServicesImpl.getService(ServicesImpl.java:72)
at
weblogic.security.service.internal.WLSIdentityServiceImpl.initialize(Unknown
Source)
at
weblogic.security.service.CSSWLSDelegateImpl.initializeServiceEngine(Unknown
Source)
at weblogic.security.service.CSSWLSDelegateImpl.initialize(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.InitializeServiceEngine(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initializeRealm(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.loadRealm(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initializeRealms(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initialize(Unknown
Source)
at weblogic.security.service.SecurityServiceManager.initialize(Unknown
Source)
at weblogic.security.SecurityService.start(SecurityService.java:141)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
With code snippet:
===starts==
import org.apache.logging.log4j.core.LoggerContext;
import org.apache.logging.log4j.LogManager;
...
...
public final class MyAuditProviderImpl implements AuditProvider, AuditChannel{
...
...
public void initialize(ProviderMBean mbean, SecurityServices services){
...
...
LoggerContext ctx = null;
Configuration config = null;
Map mp = null;
ctx = (LoggerContext) LogManager.getContext(false);
mp = config.getAppenders();
System.out.println(***MyAudit Provider o/p follows Before logger
re-configuration:);
System.out.println(\tAppenders: + mp.keySet());
...
...
}
}
===ends==
- with least hope to solve this issue, I also merged the two jars carefully
(making sure MANIFEST.MF has all the entries) into single one but still same
issue.
Hope this helps in someway to identify what is going wrong.
I am ready to test to collect any additional data for debugging.
Thanks
was (Author: pirabid):
Hi,
I am also hitting the same ClassCastException issue while trying to run the
log4j2 in WebLogic application server. Here is what I have done:
- if I put the api and core jars into DOMAIN_HOME/lib (equivalent to adding the
jars into server classpath) things run okay.
- if I put the api and core jars into
WL_HOME/server/lib/mbeantypes/3rdpartyjars, then this classcast exception is
thrown:
java.lang.ClassCastException:
org.apache.logging.log4j.simple.SimpleLoggerContext
at
com.qnb.itd.wls.sec.providers.QNBAuditProviderImpl.initialize(QNBAuditProviderImpl.java:108)
at
com.bea.common.security.internal.legacy.service.SecurityProviderImpl.init(SecurityProviderImpl.java:65)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:363)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:315)
at
com.bea.common.engine.internal.ServiceEngineImpl.lookupService(ServiceEngineImpl.java:257)
at
com.bea.common.engine.internal.ServicesImpl.getService(ServicesImpl.java:72)
at
weblogic.security.service.internal.WLSIdentityServiceImpl.initialize(Unknown
Source)
at
[jira] [Comment Edited] (LOG4J2-461) ERROR StatusLogger Unable to locate a logging implementation, using SimpleLogger
[
https://issues.apache.org/jira/browse/LOG4J2-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979390#comment-13979390
]
Abid edited comment on LOG4J2-461 at 4/24/14 7:32 AM:
--
Hi,
I am also hitting the same ClassCastException issue while trying to run the
log4j2 in WebLogic application server. Here is what I have done:
- if I put the api and core jars into DOMAIN_HOME/lib (equivalent to adding the
jars into server classpath) things run okay.
- if I put the api and core jars into
WL_HOME/server/lib/mbeantypes/3rdpartyjars, then this classcast exception is
thrown:
java.lang.ClassCastException:
org.apache.logging.log4j.simple.SimpleLoggerContext
at
com.qnb.itd.wls.sec.providers.MyAuditProviderImpl.initialize(MyAuditProviderImpl.java:108)
at
com.bea.common.security.internal.legacy.service.SecurityProviderImpl.init(SecurityProviderImpl.java:65)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:363)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:315)
at
com.bea.common.engine.internal.ServiceEngineImpl.lookupService(ServiceEngineImpl.java:257)
at
com.bea.common.engine.internal.ServicesImpl.getService(ServicesImpl.java:72)
at
weblogic.security.service.internal.WLSIdentityServiceImpl.initialize(Unknown
Source)
at
weblogic.security.service.CSSWLSDelegateImpl.initializeServiceEngine(Unknown
Source)
at weblogic.security.service.CSSWLSDelegateImpl.initialize(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.InitializeServiceEngine(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initializeRealm(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.loadRealm(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initializeRealms(Unknown
Source)
at
weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initialize(Unknown
Source)
at weblogic.security.service.SecurityServiceManager.initialize(Unknown
Source)
at weblogic.security.SecurityService.start(SecurityService.java:141)
at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
With code snippet:
===starts==
import org.apache.logging.log4j.core.LoggerContext;
import org.apache.logging.log4j.LogManager;
...
...
public final class MyAuditProviderImpl implements AuditProvider, AuditChannel{
...
...
public void initialize(ProviderMBean mbean, SecurityServices services){
...
...
LoggerContext ctx = null;
Configuration config = null;
Map mp = null;
ctx = (LoggerContext) LogManager.getContext(false);
mp = config.getAppenders();
System.out.println(***MyAudit Provider o/p follows Before logger
re-configuration:);
System.out.println(\tAppenders: + mp.keySet());
...
...
}
}
===ends==
- with least hope to solve this issue, I also merged the two jars carefully
(making sure MANIFEST.MF has all the entries) into single one but still same
issue.
Hope this helps in someway to identify what is going wrong.
I am ready to test to collect any additional data for debugging.
Thanks
was (Author: pirabid):
Hi,
I am also hitting the same ClassCastException issue while trying to run the
log4j2 in WebLogic application server. Here is what I have done:
- if I put the api and core jars into DOMAIN_HOME/lib (equivalent to adding the
jars into server classpath) things run okay.
- if I put the api and core jars into
WL_HOME/server/lib/mbeantypes/3rdpartyjars, then this classcast exception is
thrown:
java.lang.ClassCastException:
org.apache.logging.log4j.simple.SimpleLoggerContext
at
com.qnb.itd.wls.sec.providers.MyAuditProviderImpl.initialize(QNBAuditProviderImpl.java:108)
at
com.bea.common.security.internal.legacy.service.SecurityProviderImpl.init(SecurityProviderImpl.java:65)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:363)
at
com.bea.common.engine.internal.ServiceEngineImpl.findOrStartService(ServiceEngineImpl.java:315)
at
com.bea.common.engine.internal.ServiceEngineImpl.lookupService(ServiceEngineImpl.java:257)
at
com.bea.common.engine.internal.ServicesImpl.getService(ServicesImpl.java:72)
at
weblogic.security.service.internal.WLSIdentityServiceImpl.initialize(Unknown
Source)
at
[jira] [Updated] (LOG4J2-611) Logj 1.2 emulation is not complete
[
https://issues.apache.org/jira/browse/LOG4J2-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-611:
--
Priority: Minor (was: Major)
Logj 1.2 emulation is not complete
--
Key: LOG4J2-611
URL: https://issues.apache.org/jira/browse/LOG4J2-611
Project: Log4j 2
Issue Type: Bug
Components: log4j 1.2 emulation
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
The class org.apache.log4j.spi.LoggingEvent is empty, which makes Hazelcast
to fail since it tries to use this constructor:
{{org.apache.log4j.spi.LoggingEvent.init(Ljava/lang/String;Lorg/apache/log4j/Category;Lorg/apache/log4j/Priority;Ljava/lang/Object;Ljava/lang/Throwable;)V}}
It is used here (line 117):
https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/logging/Log4jFactory.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-611) Logj 1.2 emulation is not complete
[
https://issues.apache.org/jira/browse/LOG4J2-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1397#comment-1397
]
Mikael Ståldal commented on LOG4J2-611:
---
I don't like to be tied to SLF4J though, so I'm trying to get Hazelcast to
implement proper support for Log4j 2:
https://github.com/hazelcast/hazelcast/issues/2345
Logj 1.2 emulation is not complete
--
Key: LOG4J2-611
URL: https://issues.apache.org/jira/browse/LOG4J2-611
Project: Log4j 2
Issue Type: Bug
Components: log4j 1.2 emulation
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
The class org.apache.log4j.spi.LoggingEvent is empty, which makes Hazelcast
to fail since it tries to use this constructor:
{{org.apache.log4j.spi.LoggingEvent.init(Ljava/lang/String;Lorg/apache/log4j/Category;Lorg/apache/log4j/Priority;Ljava/lang/Object;Ljava/lang/Throwable;)V}}
It is used here (line 117):
https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/logging/Log4jFactory.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-611) Logj 1.2 emulation is not complete
[
https://issues.apache.org/jira/browse/LOG4J2-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980177#comment-13980177
]
Ralph Goers commented on LOG4J2-611:
I see you opened an issue with hazelcast. I think this issue should be closed
but I would be happy to review the factory you are developing for hazelcast to
make sure it will properly capture the location. However, if you used our
SLF4J or log4j bridges as an example you should be good.
Logj 1.2 emulation is not complete
--
Key: LOG4J2-611
URL: https://issues.apache.org/jira/browse/LOG4J2-611
Project: Log4j 2
Issue Type: Bug
Components: log4j 1.2 emulation
Affects Versions: 2.0-rc1
Reporter: Mikael Ståldal
Priority: Minor
The class org.apache.log4j.spi.LoggingEvent is empty, which makes Hazelcast
to fail since it tries to use this constructor:
{{org.apache.log4j.spi.LoggingEvent.init(Ljava/lang/String;Lorg/apache/log4j/Category;Lorg/apache/log4j/Priority;Ljava/lang/Object;Ljava/lang/Throwable;)V}}
It is used here (line 117):
https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/logging/Log4jFactory.java
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-613) log4j-core bundle specifies javax.servlet version range [3.0,4)
Matt Sicker created LOG4J2-613:
--
Summary: log4j-core bundle specifies javax.servlet version range
[3.0,4)
Key: LOG4J2-613
URL: https://issues.apache.org/jira/browse/LOG4J2-613
Project: Log4j 2
Issue Type: Bug
Components: Core
Affects Versions: 2.0-rc2
Environment: Felix, Karaf, ServiceMix 5.0.0
Reporter: Matt Sicker
Assignee: Matt Sicker
The Import-Package section specifies {{javax.servlet;version=[3.0,4)}} when
it should probably be {{javax.servlet;version=[2.5,4)}}. This is most likely
due to the fact that we compile against Servlet 3.0; maven-bundle-plugin is
picking up on this and using that version number for the range.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Created] (LOG4J2-614) Log4j API should allow specifying a LoggerContextFactory at runtime.
Matt Sicker created LOG4J2-614: -- Summary: Log4j API should allow specifying a LoggerContextFactory at runtime. Key: LOG4J2-614 URL: https://issues.apache.org/jira/browse/LOG4J2-614 Project: Log4j 2 Issue Type: Bug Components: API, Core Affects Versions: 2.0-rc2 Reporter: Matt Sicker Priority: Blocker The initialization code in LogManager will need to be refactored. The presence of a LoggerContextFactory implementation may not be available at the same time log4j-api is started. Thus, LogManager can shortcut to using SimpleContextFactory by default and then allow that to be overridden. This is currently a private static final field; I believe that it would be a better idea to use a sort of atomic reference pattern here (or volatile?). I'm not sure which way would be the fastest, but it shouldn't be final (I don't want to use reflection to force a different LoggerContextFactory like I'm doing for the JUL bridge I'm working on). In this scenario, it might be useful for the Loggers and LoggerContexts returned by SimpleContextFactory to be proxy classes so that they use whatever the active logger provider is. This way, if a client gets a Logger before log4j-core is activated, it can still use the proper logging objects. I don't know how much this affects performance, but java.util.logging uses a similar strategy for its loggers before java.util.logging.LogManager is initialized. Anyway, the main thing to do this here for is to allow all the other log4j JARs to not have to be fragments. This will allow for more robust OSGi integration and support in log4j-core later on (e.g., registering plugins through the OSGi service registry). It might also aid in some neat Spring integration, too (i.e., the ability to configure your loggers and appenders and such through Spring), but that's a separate idea. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [jira] [Created] (LOG4J2-614) Log4j API should allow specifying a LoggerContextFactory at runtime.
Matt, Unless you are creating an issue to immediately fix a bug, can you please have the description state what the problem or issue is? You can then either add a subsequent comment or start another paragraph in the description with a heading of “Proposed Solution”. I like to be able to understand what the issue is that needs to be solved without having to infer it by reading the description to the possible solution. Ralph On Apr 24, 2014, at 2:17 PM, Matt Sicker (JIRA) j...@apache.org wrote: Matt Sicker created LOG4J2-614: -- Summary: Log4j API should allow specifying a LoggerContextFactory at runtime. Key: LOG4J2-614 URL: https://issues.apache.org/jira/browse/LOG4J2-614 Project: Log4j 2 Issue Type: Bug Components: API, Core Affects Versions: 2.0-rc2 Reporter: Matt Sicker Priority: Blocker The initialization code in LogManager will need to be refactored. The presence of a LoggerContextFactory implementation may not be available at the same time log4j-api is started. Thus, LogManager can shortcut to using SimpleContextFactory by default and then allow that to be overridden. This is currently a private static final field; I believe that it would be a better idea to use a sort of atomic reference pattern here (or volatile?). I'm not sure which way would be the fastest, but it shouldn't be final (I don't want to use reflection to force a different LoggerContextFactory like I'm doing for the JUL bridge I'm working on). In this scenario, it might be useful for the Loggers and LoggerContexts returned by SimpleContextFactory to be proxy classes so that they use whatever the active logger provider is. This way, if a client gets a Logger before log4j-core is activated, it can still use the proper logging objects. I don't know how much this affects performance, but java.util.logging uses a similar strategy for its loggers before java.util.logging.LogManager is initialized. Anyway, the main thing to do this here for is to allow all the other log4j JARs to not have to be fragments. This will allow for more robust OSGi integration and support in log4j-core later on (e.g., registering plugins through the OSGi service registry). It might also aid in some neat Spring integration, too (i.e., the ability to configure your loggers and appenders and such through Spring), but that's a separate idea. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [jira] [Created] (LOG4J2-614) Log4j API should allow specifying a LoggerContextFactory at runtime.
Yes, that's make it easier for the rest of us to understand what is going on ;) Gary On Thu, Apr 24, 2014 at 7:40 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Matt, Unless you are creating an issue to immediately fix a bug, can you please have the description state what the problem or issue is? You can then either add a subsequent comment or start another paragraph in the description with a heading of “Proposed Solution”. I like to be able to understand what the issue is that needs to be solved without having to infer it by reading the description to the possible solution. Ralph On Apr 24, 2014, at 2:17 PM, Matt Sicker (JIRA) j...@apache.org wrote: Matt Sicker created LOG4J2-614: -- Summary: Log4j API should allow specifying a LoggerContextFactory at runtime. Key: LOG4J2-614 URL: https://issues.apache.org/jira/browse/LOG4J2-614 Project: Log4j 2 Issue Type: Bug Components: API, Core Affects Versions: 2.0-rc2 Reporter: Matt Sicker Priority: Blocker The initialization code in LogManager will need to be refactored. The presence of a LoggerContextFactory implementation may not be available at the same time log4j-api is started. Thus, LogManager can shortcut to using SimpleContextFactory by default and then allow that to be overridden. This is currently a private static final field; I believe that it would be a better idea to use a sort of atomic reference pattern here (or volatile?). I'm not sure which way would be the fastest, but it shouldn't be final (I don't want to use reflection to force a different LoggerContextFactory like I'm doing for the JUL bridge I'm working on). In this scenario, it might be useful for the Loggers and LoggerContexts returned by SimpleContextFactory to be proxy classes so that they use whatever the active logger provider is. This way, if a client gets a Logger before log4j-core is activated, it can still use the proper logging objects. I don't know how much this affects performance, but java.util.logging uses a similar strategy for its loggers before java.util.logging.LogManager is initialized. Anyway, the main thing to do this here for is to allow all the other log4j JARs to not have to be fragments. This will allow for more robust OSGi integration and support in log4j-core later on (e.g., registering plugins through the OSGi service registry). It might also aid in some neat Spring integration, too (i.e., the ability to configure your loggers and appenders and such through Spring), but that's a separate idea. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: Quick note about Marker construction and null.
It sounds reasonable to me to require a non-null name. On Wed, Apr 23, 2014 at 10:17 AM, Matt Sicker boa...@gmail.com wrote: There's no point in using a null-named Marker, right? Many methods don't allow for a null argument for Marker name, but the constructor does. I'm going to change this. -- Matt Sicker boa...@gmail.com -- Bruce Brouwer
Re: Some things I noticed with the Marker implementation
The only reason to have more than the single vararg version is for performance. I don't think the marker .add method is going to be called often so ultra-performance is not necessary. I say don't bother with the one or two param variant. I just want the varargs version. On Tue, Apr 22, 2014 at 8:30 PM, Matt Sicker boa...@gmail.com wrote: On Tuesday, 22 April 2014, Bruce Brouwer bruce.brou...@gmail.com wrote: I don't think performance is a real concern on this method. Style is what I am concerned about. My vote would be to change the add method to accept varargs. We could include both. Or have one, two, and variable versions. On Apr 22, 2014 11:45 AM, Ralph Goers ralph.go...@dslextreme.com wrote: I thought about the add method with multiple arguments but thought that it sort of goes against the builder pattern. However, I am sure it would perform better. Ralph On Apr 22, 2014, at 5:18 AM, Bruce Brouwer bruce.brou...@gmail.com wrote: Don't worry about the part of my comment that you were confused about. I see now that varargs are not slower than array parameters, so long as you pass in an array. 1) I did find some other things to talk about. This comment: // It is not strictly necessary to copy the variable here but it should perform better than // Accessing a volatile variable multiple times. I believe should be removed. This method is not synchronized so iterating over an array of 5 elements while another thread removes an element would cause the array to shrink to 4 and cause a possible ArrayIndexOutOfBounds exception. I believe it is absolutely necessary to make a copy of the array. 2) Something I missed earlier regarding add that your FIXME reminded me of. I would like to see the add method take varargs so that I can add more than one parent at a time. I know the fluent nature means I could just call marker.add(name1).add(name2), but why not marker.add(name1, name2)? 3) public boolean isInstanceOf(final String markerName) checks for a null MarkerName and throws IllegalArgumentException, but the current implementation allows a null marker name. I believe that check should be removed and code it so nulls can be handled in the method. Either that or make the other methods throw exceptions if you pass in a null marker name. It is possible that adding null checks will slow this method down so I won't be surprised if we change other methods to disallow null marker names. 4) Please make the FIXME in isInstanceOf happen that returns false instead of throwing IllegalArgumentException when the marker does not exist. On Tue, Apr 22, 2014 at 12:18 AM, Matt Sicker boa...@gmail.com wrote: Actually, now I'm confused about that. Bruce, could you take a look at the current trunk version of MarkerManager? On 21 April 2014 21:48, Ralph Goers rgo...@apache.org wrote: I'm not sure what you are referring to - the parameters? Using a copy of a volatile reference is usually faster than using the volatile reference itself. I think that is what Bruce is referring to. Ralph On Apr 21, 2014, at 7:20 PM, Matt Sicker boa...@gmail.com wrote: Using Marker... or Marker[] compile to the same bytecode. It should only affect compile-time stuff unless I'm mistaken. On 21 April 2014 20:17, Bruce Brouwer bruce.brou...@gmail.com wrote: Yes, I did. The arrays are faster in 90% of cases. The only time I got the HashSet to be faster was when I was caching the entire marker hierarchy and the hierarchy was more than 3 levels deep. That is definitely not the most common case. Also, I think the Marker... localParents parameter might be more performant as Marker[] localParents On Mon, Apr 21, 2014 at 10:07 PM, Matt Sicker -- Matt Sicker boa...@gmail.com -- Bruce Brouwer
