I am developing an Eclipse RCP application and have gone to some pains to get log4j2 to work within the app. All seems to work fine now, and as a finishing touch I wanted to make all loggers asynchronously.
I've managed to get the LMAX Disruptor on the classpath, and think I've solved the issue of providing sun.misc as well. Set the VM argument -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector in the run config and set up log4j2.xml file correctly as well. I think. And that's where the problem is. I'd like to be able to verify that my application logs asynchronously in the proper fashion, so I can enjoy the benefits latency-wise.
How can I - then - verify that my loggers are working asynchronously, utilising the LMAX Dirsuptor in the process?
There are two types of async logger, handled by different classes.
All loggers async: the AsyncLogger class - activated when you use AsyncLoggerContextSelector
Mixing sync with async loggers: the AsyncLoggerConfig class - when your configuration file has <AsyncRoot> or <AsyncLogger> elements nested in the configuration for <Loggers>.
In your case you are making all loggers async, so you want to put your breakpoint in AsyncLogger#logMessage(String, Level, Marker, Message, Throwable).
Another way to verify is by setting <Configuration status="trace"> at the top of your configuration file. This will output internal log4j log messages on log4j is configured. You should see something like "Starting AsyncLogger disruptor...". If you see this all loggers are async.
Put a breakpoint in org.apache.logging.log4j.core.async.AsyncLoggerConfig#callAppenders. Then you can watch as the event is put into the disruptor. Likewise org.apache.logging.log4j.core.config.LoggerConfig#callAppenders should be getting hit for synchronous logging OR getting hit from the other side of the disruptor for async logging (at which point everything is synchronous again).
Related
We are using cas-client-core-3.3.3.jar for providing single sign on functionality in our application and we are trying to emit this jar library logs into our appliation logs.
Our application is a weblogic based application and we are using log4j for logging.
So to get cas-client-core-3.3.3.jar logs in our application log we have added this property in our log4j.properties
log4j.logger.org.jasig.cas=DEBUG
but we are not getting the logs which are expected from org.jasig.cas classes. I am attaching sample log here which is expected
2015-05-13 10:00:17,798 DEBUG [org.jasig.cas.client.validation.Saml11TicketValidator.<constructValidationUrl>] - Placing URL parameters in map.
2015-05-13 10:00:17,801 DEBUG [org.jasig.cas.client.validation.Saml11TicketValidator.<constructValidationUrl>] - Calling template URL attribute map.
2015-05-13 10:00:17,802 DEBUG [org.jasig.cas.client.validation.Saml11TicketValidator.<constructValidationUrl>] - Loading custom parameters from configuration.
2015-05-13 10:00:17,803 DEBUG [org.jasig.cas.client.validation.Saml11TicketValidator.<validate>] - Constructing validation url:
Disclaimer: I've never worked with Web Sphere but worked a lot with different logging systems, so my answer is based on my experience in this area.
First off, cas uses slf4j under the hood which is great.
Slf4j is only an interface (slf4j-api jar), and if you want to use it with log4j which is a concrete implementation of logging system that knows nothing about slf4j apis you should provide an implementation of sfl4j interfaces that will delegate the calls to log4j loggers.
So you should also include such an adapter in classpath as well Here is the link.
Now if this doesn't work, then probably the log4j.properties are not configured correctly, for example, the logger doesn't have any associated appenders/wrong appenders.
I've found the best way to check this is just to place a breakpoint on the logger's call (inside cas library) and see the following:
Which implementation of slf4j interface is actually used (as I've said before org.sl4j.Logger is just an interface and it has to be instantiated with real implementation object somehow, you know)
See the associated appenders to the underlying implementation.
Regarding the second item, depending on technology/frameworks you have, you might be able to get this information via JMX or some kind of web admin interface. Debugging is a "hardcore" general way to figure this out.
i just created my own appender as base of Logback document chapter 4 (see Writing your own Appender section).
Whatever is being logged at INFO level in my application, My appender gets invoked and post that message as http message to the servlet running on other end.
these kind of logic makes my application to slow down. because the appender runs on same thread which application is running. How do i make my appender to run in separate thread ?
Since Logback is based on Log4J, you should be able to used asynchronous logging option. See here This makes sure that your logging process runs in a separate thread.
I just read the gwt-log Getting Started guide and found it very helpful, however I have a few questions surrounding the Loggers:
The SystemLogger sends output to System.err and System.out - in the context of a client-side web app running inside a browser, where will this output eventually go? Browser logs?
Does RemoteLogger depend on JUL or log4j? I have a homegrown slf4j binding that I like to use for all my Java backends, and would like to use it, but not sure if RemoteLogger will be incompatible with it?
Is it possible to have RemoteLogger hit my own LoggingServiceServlet, which could then translate the log messages coming in on the HttpServletRequest into logging statements that are compatible with my custom slf4j binding? If so, what might this config look like?
Thanks in advance!
In this link, you have a most updated documentation about the GWT logging framework
Answers to your questions:
#1 Yes it works in client side, but only when running the app in DevMode (not in production nor superdev mode). Look for the log lines in the DevMode window, or in your terminal output if you run dev-mode from the command-line.
#2 It depends on java.util.logging, you can change it though (see #3)
#3 Yes you can change the logging framework extending the RemoteLoggingServiceImpl and overriding the logOnServer(LogRecord lr) method.
I'm new to logback. I quite fascinated by it but I'm not sure if it suits my use-case.
I would like to have a logger that I can stop and start. While it is stopped I would like to remove the log file from the filesystem. When logging is restarted the file should be re-created.
Is logback capable of this? While the logging is paused, should I avoid calling a Logger in my classes, or can logback handle this?
I use a slf4j.Logger currently. In the manual I saw that Appender objects implement the LifeCycle interface, which implies that they implement start(), stop() and isStarted().
I thought this means they can be stopped so I can move the file, but later on it goes:
If the appender could not be started or if it has been stopped, a
warning message will be issued through logback's internal status
management system. After several attempts, in order to avoid flooding
the internal status system with copies of the same warning message,
the doAppend() method will stop issuing these warnings.
Does it mean that I can stop it, then remove the file, then restart?
I would like to have a logger that I can stop and start. While it is stopped I would like to remove the log file from the filesystem. When logging is restarted the file should be re-created.
I'm not sure how to accomplish this programmatically but you can accomplish this via JMX if you've added jmxConfigurator to the logback.xml config file.
<configuration>
<jmxConfigurator />
...
This exposes the ch.qos.logback.classic.jmx.JMXConfigurator bean which has an operation entitled reloadDefaultConfiguration. When I press that at runtime, the logfiles are reopened. See Jconsole image below. This means that a jmx client (such as the one in my SimpleJMX library for example) would be able to do that from the command line.
If you are trying to it programmatically from inside of the same application then you should be able to get ahold of the mbean and trigger the call yourself. Something like seems to work for me:
ManagementFactory.getPlatformMBeanServer().invoke(new ObjectName(
"ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator"),
"reloadDefaultConfiguration", null, null);
What I would do is rename the logfile(s) to a different name(s) and then issue the reload configuration command. Then the renamed files can be archived or removed after the new files are created.
Hope this helps.
I have a log4j with several loggers, appenders used in a multi-threaded application. In one scenario, I will try to connect to a remote service. If the connection fails, I will try again repeatedly.
I would like that only the first time log4j uses its original configuration. But for every other subsequent attempts, I want to use a less verbose configuration. This should not change the logging configuration of the other threads that might operate on the same objects. Note that I cannot know in advance which loggers are used inside the call to connect to the remote service.
So, is there a way to alter the logging globally for the duration of one call without changing the behavior of other concurrent threads?
Look at this part of the API:
http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Logger.html
You can call the setLevel(Level lev) method and do some changes. However, I'm not 100% sure that you won't affect other threads as normally the Logger is based on a class.
I would think that you would have to get a Logger object for each user session, but I'm not 100% sure if it could cause heap issues.
Maybe controlling the output from your code (only send some messages to the log if it's the first attempt for instance).
Regards