Here is my Hazelcast deployment procedure in two steps:
1) Download the Hazelcast jar at:
https://repo1.maven.org/maven2/com/hazelcast/hazelcast-all/$HAZELCAST_VERSION/hazelcast-all-$HAZELCAST_VERSION.jar
2) Deploy Hazelcast using the command:
java -server $JAVA_OPTS com.hazelcast.core.server.StartServer
Without deviating much from the described procedure, it there a way to set the log level?
More specifically what I'm looking for is something like adding a flag similar to -Djava.util.logging.level=WARN to filter out the info logs, but I have been unsuccessful so far.
I'm trying to avoid using alternative log libraries and xml configuration files for this purpose.
Thank you for your attention
Hazelcast provides multiple ways you can configure the logger. This may be helpful.
Using JVM parameter: java -Dhazelcast.logging.type=log4j
Using System class: System.setProperty( "hazelcast.logging.type", "log4j" );
and in the log4j, add the following.
<logger name="com.hazelcast">
<level value="warn" />
</logger>
Logging Configuration
I believe it's more like a logging config question, rather than Hazelcast. java.util.logging, like other logging frameworks, uses a config file, which you can point using java.util.logging.config.file param. Or you create a LogManager and point it with java.util.logging.config.class param.
Hazelcast doesn't have any internal logging library, just uses java.utl.logging. To configure it, you need to look that logging framework's config options.
Related
I'm used to using log4j and whenever there were setup/config problems I'd enable "-Dlog4j.debug" and all the config info would be dumped out at startup.
This was very useful on a number of occasions.
Now I'm working on a Spring boot application, which I've found uses:
Commons logging Logger statements in the client code
A bridge jar (jcl-over-slf4j-xxx.jar) which translates the commons logging calls into slf4j more info here
Finally slf4j uses "logback" as the underlying logging framework
I found it rather painful to figure all this out.
Is there an equivalent of -Dlog4j.debug which can show me how this is all hanging together at startup time?
This is the best/only option I've found so far, and it's logback specific.
Use this -D on the command line:
-Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener
Taken from here
This essentially is the logback equivalent of log4j's -Dlog4j.debug.
It dumps the logback startup sequence to the console at startup time, as the logging system is initialised.
This is not a true answer as I'd like some messages to show before this to show why logback is being used, but I haven't found anything like that yet.
Aside: This may also be useful for Spring Boot:
-Ddebug
Taken from here and here
If you are using logback, I assume you are using the logback.xml file? Then if you start that file with <configuration debug="true"> then it should dump the status information. More information in the documentation under status data section.
I want to log Request/Response of my server in log files. I am using Springboot + jersey 2.x + log4j2. I registered jersey's LoggingFeature like this -
jerseyConfig.register(
new LoggingFeature(
java.util.logging.Logger.getLogger(
LoggingFeature.DEFAULT_LOGGER_NAME),
java.util.logging.Level.SEVERE,
LoggingFeature.Verbosity.PAYLOAD_ANY,
Integer.MAX_VALUE)
);
log4j2.xml
<!-- Jersey logger -->
<AsyncLogger name="org.glassfish" level="all" additivity="false">
<AppenderRef ref="Console" level="off" />
<AppenderRef ref="RollingFileIO" level="error" />
</AsyncLogger>
In pattern, I am injecting transaction-id with help of log4j2's ThreadContext. I have log4j-jul 2.1 in my pom.xml, and I am running it with
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager .
Things are working fine, only problem is, in jersey's logs, I am unable to insert transaction id. I tried utils logging with my custom code, and I am able to put transaction-id in it. But by the time jersey writes these logs, ThreadContext gets cleared and transaction-id values comes empty.
If the log flow is JUL->log4j2->FooAppender->Layout->ThreadContext.pop then
Per Including the ThreadContext when writing logs:
The PatternLayout provides mechanisms to print the contents of the ThreadContext Map and Stack.
Use %X by itself to include the full contents of the Map.
Use %X{key} to include the specified key.
Use %x to include the full contents of the Stack.
If the flow is log4j2->JUL->FooHandler->Formatter->ThreadContext.pop then you have to install or create a formatter that is aware of the ThreadContext. You also have make sure in this configuration that log4j2->ThreadContext.pop->JUL->FooHandler->Formatter is not happening as that would forget all of the information before it gets to JUL.
All of the examples in the documentation show the ThreadContext is set prior to invoking the logger. Which means you have to set the ThreadContext prior to any Jersey code execution.
I haven't looked at Jersey in detail but from the problem description it seems that it has a thread model that makes working with ThreadContext difficult.
Fortunately Log4j 2.7 offers a facility to let you inject key-value pairs (like ID) into log events from another source than the ThreadContext. This was introduced to help with asynchronous frameworks like Finagle, so it may be useful for Jersey as well.
The Log4j2 manual briefly mentions this feature in the section on Custom ContextDataInjectors.
If you want to use this facility you need to write a custom ContextDataInjector and tell Log4j to use that injector instead of the default one by specifying a ContextDataInjectorFactory. Your custom injector needs to get the key-value pairs from somewhere. In Jersey's case, would RequestContext.getProperty and setProperty be appropriate?
Is it possible to transfer the AEM (v5.6) logs to the Log4j server? Or there is some best practice for centralized AEM logging?
I haven't dealt much with AEM. It seems the Apache Sling Logging services configure only the FileAppender.
For CQ5.5 there is no log4j.xml. All the CRX logger needs to
configured using sling config.
We can use Apache Sling Logging Logger
Configuration
(https://docs.adobe.com/docs/en/aem/6-0/deploy/configuring/monitoring-and-maintaining.html#Create%20a%20Custom%20Log%20File)
or LogBack
(http://sling.apache.org/documentation/development/logging.html#logback-integration)
AEM provides the loggers out of the box as you have seen. Typically if you want centrallized log handling I would suggest mounting a super-high-speed shared volume and having all instances log there, just for performance/speed reasons.
You might want to check out this:
http://adobe-consulting-services.github.io/acs-aem-commons/features/syslog-appender.html
It is AEM6 only, but you could look at the code and do it that way.
This uses logback, not log4j, but it should solve your problem.
The other option, really, is to write your own logging service and use that and configure the appender in the code. I do not see the normal XML files anywhere. I'm curious if you come across them.
Let me know if I can help further.
I'd like to configure log4j in a huge distributed system. There are a lot of JVMs and processes and (as I am only a student) I am new to such a situation. I use JMS Appender, so I need two files: log4j.properties, jndi.properties.
I've tried some ways:
Put these files into src folder
or into src/java
add jvm argument -Dlog4j.configuration=C:\...\log4j.properties
I don't want to set it in code using PropertyConfigurator.configure("path"), because I'd like to not change source code at all.
Are there any other ways to configure log4j? Or maybe I am missing something? I still get a messages
No appenders could be found for logger (some.package.SomeClass).
Please initialize the log4j system properly.
basically you have the following ways to configure Log4J:
Via your code
properties file (as you're trying to use)
Xml File
What you're asking to me related to specific configuration of JMS appender and its not about 'general way of how to configure log4j'
Here is an example of how to configure it with ActiveMQ
For other JMS implementations in your property file the keys will be probably the same but the values will be different
Example - using JMS appender with ActiveMQ
I'm using Hibernate's c3p0 connection pooling and standard Java 1.4 java.util.logging. Upon startup, my app sets up it's logging properties (including formatter and log levels) in static block. Every time I start my app, I see the following:
2011-04-16 17-43-51 [com.mchange.v2.log.MLog] INFO: {MLog.<clinit>) MLog clients using java 1.4+ standard logging.
2011-04-16 17-43-51 [com.mchange.v2.c3p0.C3P0Registry] INFO: {C3P0Registry.banner) Initializing c3p0-0.9.1 [built 16-January-2007 14:46:42; debug? true; trace: 10]
2011-04-16 17-43-51 [com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource] INFO: {AbstractPoolBackedDataSource.getPoolManager)
...
I've tried
Logger.getLogger("com.mchange").setLevel(Level.WARNING);
com.mchange.v2.log.MLog.getLogger().setLevel(MLevel.WARNING);
System.setProperty("com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL", "WARNING");
but only way to prevent it that I found for now is
Logger.getLogger("").setLevel(Level.WARNING);
which affects everything - not a good side effect. Google didn't help. Could anyone help please?
The way I found is to set the system property
System.setProperty("com.mchange.v2.log.MLog", "com.mchange.v2.log.FallbackMLog");
in addition to
System.setProperty("com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL", "WARNING");
I thought, that absence of any other logging system wil make that optional, but it seems, that I was wrong.
P.S.
Damn those wheel-reinvented custom logging implementations, like the one used by c3p0...
The way I found for achieving this
Create in your classpath a file called mchange-log.properties and put into it properties suggested by Frozen Spider.
com.mchange.v2.log.MLog=com.mchange.v2.log.FallbackMLog
com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL=WARNING
Thats work fine even when you are not able to set system properties directly.
It appears that c3p0 logging defaults to DEBUG. That can result in a lot of noise.
By adding a line like this to log4j.properties, you are telling the logger not to bother you with c3p0 messages - unless it's something important:
log4j.logger.com.mchange.v2=WARN
Do you not want to see any c3p0 logging?
If so try:
Logger.getLogger("com.mchange.v2.c3p0").setLevel(Level.WARNING);
OR, if you don't even want to see the first line of the log:
Logger.getLogger("com.mchange.v2").setLevel(Level.WARNING);
This is probably really late, but according to the c3p0 project website it is possible to configure the logging inside the mchange-log.properties so that you can capture the information using slf4j or log4j (and thus also with Logback).
The link http://www.mchange.com/projects/c3p0/#configuring_logging provides this information that in your mchange-log.properties file set the property com.mchange.v2.log.MLog to equal com.mchange.v2.log.slf4j.Slf4jMLog then in your logback.xml you can provide a logger like this:
<logger name="com.mchange" level="warn" additivity="false">
<appender-ref ref="c3p0-log" />
</logger>
Note: you will need to create a logback appender called c3p0-log before you can use this exact piece of code.
create a file called log4j.properties in your root classpath
set the following in there,
# Configure the name of the file for the LOGGER appender
log4j.appender.LOGGER=org.apache.log4j.ConsoleAppender
log4j.appender.LOGGER.layout=org.apache.log4j.PatternLayout
log4j.appender.LOGGER.layout.ConversionPattern=%d{MM-dd#HH:mm:ss} %-5p (%13F:%L) %3x - %m%n
log4j.appender.LOGGER.append=false
# this line logs everything from hibernate package at info level, you can refine this to include only some pachages like log4j.logger.org.hibernate.hql etc.,
log4j.logger.org.hibernate=INFO, LOGGER
log4j.logger.org.jboss.cache=INFO, LOGGER
this is a much better way of implementing the logging because if you set the logging strategy programmatically, then the config sometimes might not take effect at all (like in your case).. if you use the log4j.properties file ,the config is applied at application startup & everything works smoothly.
This only happens on older c3p0 version. So it might also be worth checking if you can just update to a newer version.