Just installed log4j and got it working pretty well, but I noticed because netty also uses log4j, im getting all the log messages from netty too. Is there any way I can configure log4j to ignore netty?
also as a side note if theres any way I can configure log4j so I don't have to type
static Logger log = Logger.getLogger(Yourclass.class);
in every class that be great to know too
You can change the log level for io.netty to WARN or ERROR. If you are not familiar with log4j configuration, please read this and this.
Related
Is Log4J still vulnerable when logging is turned off?
One of the programs use version 1 of Log4J. I turned it off this way -
logger.level: OFF
The app does not generate anymore logs, would it be still vulnerable?
I'm having some struggles getting a Java web-application running on IBM WebSphere Application Server 9.0.5.5 sending messages to an IBM MQ topic using log4j 1.2.17.
In WAS we originally had a ConnectionFactory set up to use to communicate with the topic. This is what we do with other applications that use IBM MQ queues. However, this ends up giving me the following error:
java.lang.ClassCastException: com.ibm.ejs.jms.JMSConnectionFactoryHandle incompatible with javax.jms.TopicConnectionFactory
I found an IBM article that discusses a similar issue with queues and the solution is to use a QueueConnectionFactory. So, similarly I switched from using a ConnectionFactory to a TopicConnectionFactory. Now I get this error:
java.lang.ClassCastException: com.ibm.ejs.jms.JMSTopicConnectionFactoryHandle incompatible with javax.jms.TopicConnectionFactory
I have another Java web-application that uses log4j2 with queues. We have a ConnectionFactory set up in WAS in Resources > JMS as we did here with this application. It all works fine. The only difference here is that we are using log4j 1.2.17 and topics instead of queues.
I cannot change the version of log4j because it is baked into the vendor platform we have.
I checked the WAR file that is being deployed and there is only the one jms.jar (and fscontext, providerutil, mq, etc. JARs for IBM MQ Client 9.1.0.0) in there. So no other competing jms.jar that might be of an older JMS version.
Any ideas what could be wrong here?
This took A LOT of back and forth with IBM to get it to work. I'd have to go through the case history, but for now I can just share what I see in our JMS configuration in WAS.
In each environment, we are running with 2 WAS nodes.
On each WAS node, we created a Topic connection factory with scope at the Node level.
In the factory, we have both of our MQ servers for that environment listed in our Connection name list
We also set up a JAAS - J2C authentication resource as a user id is required to access our MQ servers.
We also created a Topic object at the Node scope level.
That's basically it. Now, we did have a lot of issues on the MQ side with permissions not being set up properly that IBM was able to identify in some traces we sent.
I'd say if you are still stuck, open a case with IBM. It took a little while to get to the right resources, but after running some traces they were able to find our issues.
Good luck #rajib-biswas!
I've been working on getting an ELK stack setup to have our logs centralized and easier to check, but I'm running into a bit of a snag.
I've modified a few of our java programs to use the socket appender from log4j and it's worked great each time. Now I'm trying to add it to karaf to have all of our karaf logs recorded but it doesn't seem to be working.
I added:
log4j.rootLogger=INFO, logstash, osgi:*
# Logstash appender
log4j.appender.logstash=org.apache.log4j.net.SocketAppender
log4j.appender.logstash.Port=PORT
log4j.appender.logstash.RemoteHost=HOST
log4j.appender.logstash.ReconnectionDelay=10000
to the file in {karaf_home}/etc/org.ops4j.pax.logging.cfg (with the correct port/host obviously) and then restarted karaf just to make sure (something I read said it would pick up changes automatically but I didn't know if I trusted it so I restarted it anyway) but nothing seems to be making it from karaf to our ELK stack. When I do log:display on the karaf console I see plenty of messages being written to the log, but none in ELK.
Any clue as to why this may not be working for karaf, but is working for other projects using the same appender?
You should have a look at karaf decanter. It already contains connectors that can be used to send logs to an ELK stack, the decanter-collector-log is probably what you are looking for
I want to implement same logfile for different appenders ..Is it possible to do so?or should i have to use different log files?
To be on the safe side it is probably better not to do this as it could lead to synchronization issues, deadlock or corrupt log files.
However, logback (log4j's successor) allows this, in prudent mode.
Another alternative, is to have your multiple appenders log to a single SocketAppender and have the receiving socket log to a file.
Don't know log4j, but log4net has ForwardingAppender and BufferingForwardingAppender, and I guess it's probably similar.
So presumably you could have multiple ForwardingAppenders that all forward to the same FileAppender.
This is my situation. I have successfully implemented logging to remote syslog using log4net. However, as far as I could test, if syslog IP is not valid, all messages will not log anywhere and no exception is raised. It just does nothing.
Hence, it would be nice to have some sort of fallback. Let's say if writing to syslog fails, write to file or to database.
Is that even possible with log4net? Or would I have to configure it to log to two locations at the same time?
I don't think you can do this by configuration. This issue is open in the log4net feature backlog.
If your application can eat the logging overhead, the easiest solution would be to log to an alternative appender by default.
Alternatively you could try to wrap the appender you're using in a custom appender, and implement the fallback scenario if the syslog appender throws an exception. If it doesn't swallow them silently.
From log4net FAQ:
You can implement the log4net.Appender.IAppender interface to create you own customized appender. We recommend that you extend the log4net.Appender.AppenderSkeleton class rather than starting from scratch. You should implement your custom code in a assembly separate from the log4net assembly.
To get started it is worth looking at the source of the log4net.Appender.TraceAppender as an example of the minimum amount of code required to get an appender working.
Third option would be to look into the source code of your appender and see if you can fork it and do the necessary customizations there.