Errors/Exceptions in applications are currently logged to a log file. Unless someone examines these log files, we don't get visibility into number of errors happening. We are looking for a web application that can display different types of exceptions, their stats (graphs), etc. so that anyone can easily look at the interface or set up monitors to send an email when more than x errors happen in an application.
What are the best practices to monitor for exceptions and get notified?
Try JSnapshot, it may be very useful for you.
Related
Why printStackTrace is not recommended to use in oracle ATG. If anyone knows please tell me.
Thanks in advance.
Avoiding the use printStackTrace is not just limited to ATG but should be applied to JAVA development in general. The SonarQube validation rules explains it as follow:
Throwable.printStackTrace(...) prints a throwable and its stack trace
to some stream. Loggers should be used instead to print throwables, as
they have many advantages:
Users are able to easily retrieve the logs.
The format of log messages is uniform and allow users to browse the logs easily
With the availability of logError you are able to easily spool your error messages, not only to the standard dynamo.log and error.log but you can also see them in context of the rest of your application logs.
There is another SO question touching the same topic available here.
Is it possible to expose sensitive application or system information via Java Exceptions when trust boundaries cross?
I mean, not just theoretically but if that happens in real environment.
e.g. java.io.FileNotFoundException might tell the caller about my application's file system structure etc .
java.util.ConcurrentModificationException
might give info about non-threadsafe classes of my app.
Can this situation be handled in any other way than the below two?
Use Sysouts ( with only a customized message ) instead of throwing exceptions for codes which are supposed to be accessed by others?
If its mandatory to throw exception, sanitize your messages and then throw exception
I am also wondering if point # 2 is completely avoidable and there would not be any mandatory situations for throwing exception.
My question is not about any specific application but programming practice in general ( where inter - application communication is needed in large enterprises like two different Banks etc ).
The most common way of exposing sensitive information is to give the user (client) of the program a stack trace.
A stack trace is useful for programmers debugging a problem, and not to anyone else. So logging code should not output stack traces as a matter of course. It should output them only when an exception indicates a bug in the program. And it should output them where they can be made available to a programmer, but to as few others as possible.
If a program has a log file invisible to normal users of the program but visible to administrators (as is the case with servers), that is an appropriate place to log stack traces.
Similarly arguments apply about other sensitive information.
Although your question is entirely about security concerns, this can be considered too as a user experience (user interface) issue: the messages you give to the various users of the program should be appropriate for those users, and should provide them with information that is useful to them, without extraneous information that could confuse them. In particular, the message text of an exception should not be reported to users (but should be include as part of any stack trace).
For a client-server program, the clients have no interest in the details of why the server failed to process a request sent by the client. They need to know that the request did fail. If the request failed because of a problem with the server, rather than a faulty request by the client, they need to know that is the case, so they can contact the administrators to fix the server. If the request failed because the client sent a faulty request, the client should be told that, with a description of what was faulty about the request, so the client can send a corrected request.
Also, beware that not all exceptions indicate a problem that some user must be told about. If the program automatically handles the condition signalled by an exception, in many cases there is no need to tell the user at all about the condition signalled by the exception.
I've 2 webapplications, want to log the log messages of these two web apps into only one log file. I tried this scenario, facing the issue as "If one web app logs the message into log, the second web app is not able log the message into log file". If I stop the server, the second app is able to log.Any help?
writing to the same file from multiple independant processes is a bad idea - only one of them can get a file lock, as evident from your issues.
what you need is a centralized logging server and have all of your applications log to that server over the network. see this question
You can use Log4J's SocketAppender for that, which is much cleaner - an example can be found in this article: log4j: How to use SocketAppender.
To be honest it is a bit overkill compared to having two independent logfiles for your processes.
Btw. your approach might have problems on distributed filesystems (e.g. NFS) - don't mix logfiles.
Hope that helped a bit.
*Jost
It is not good idea to put logging of two different applications to common log. Logging module lock the log file for writing. if other application is trying to access the same log, it wont get the lock.
I would avoid such things.
My application has to output content for the user. Throughout all my classes I've just been using System.out.println, but since the program isn't intended to be run by command line this isn't really suitable.
I had thought of simply making a classes that extends JPanel and having all the content append to a textarea. I've been reading that this isn't a good move, and an issue arises in that I'll have to pass the JPanel class to all the classes that output text.
Is there a good-practice alternative to System.out.println? If not, how do you suggest I proceed? I have suggestions of Java Logging, but I don't want to output to a file.
You should have limited user interaction in most of your classes and in fact the UI code should be separate in its own set of class. You should strive to write your model (non-UI) code so that it can work well in a console application, a Swing application, an SWT application or other UI library type application. This way your code can work with SOP or with GUI's as you see fit. I will wager that > 90% of Java classes created by professional coders have no UI code within them.
Also please note that logging and user interaction code are two completely orthogonal concepts. I look at logging as a way to communicate with the developer and supporter, not the user.
Agree with #Hovercraft's comment. Don't pass the JPanel, have a static method in your UI class that all other objects call when they need to output. That method will handle formatting and appending and all that.
Moreover there isn't really an alternative to println when it comes to Java. That's because println only outputs to stdout and in a GUI application it's hidden unless the user executes your program from command line.
What you want is a configurable logging framework, like Log4j. By writing a custom log appender, you have have your log output appear anywhere you want, not just in a file: http://www.javaworld.com/javaworld/jw-12-2004/jw-1220-toolbox.html
The reason is that sending messages to stdout is usually inappropriate in a production environment. If you're coding a library, the library should return information to its caller, not print to stdout. If you're coding a GUI app, the information should be presented to the user, not to where stdout happens to be pointing (which might be nowhere). If you're coding a server (or something that runs in a server-side container) you should be using whatever logging facility the framework has provided. And so forth.
The logger gives to ability to define different levels of importance of the logged messages and the ability to use different sink for the output - the console, a file, etc.
Also it's easy to enable or disable only some type of message when using a logger - for example you don't want to see every debug message in production.
I don't think that using loggers offers any significant advantages in unit tests, but I'd prefer it even there anyways. In unit tests asserts are usually my primary concern.
Btw you should really consider using something like Commons Logging or SLF4J as a log framework facade - it's bad style to tie your code to a specific logging framework. Common Logging and SLF4J make it easy to switch logging frameworks if you choose to.
The best method to output information to your user depends on the kind of app you're working on.
If your app is batch-oriented and highly technical, it might be appropriate to send output to a scrolling text area (JTextArea) so users can view the latest status and scroll back to get details if they want.
But if it's more interactive and less technical in nature, you should try to minimize output to only the most essential things, like high-level status messages, or critical error messages. Simple dialogues (JOptionPane) and status bars (JLabel) might be best in that case.
In either case, if your app is large, you should consider designing it so that you don't scatter a lot of UI code in with everything else. Keeping the main logic separate from the presentation code will help with maintenance later on. One well-accepted approach to doing that is called model-view-controller (MVC).
Here are a couple good links to get you started on MVC.
Wikipedia article on Model-view-controller
Stackoverflow question: The MVC pattern and SWING
Is there a good-practice alternative to System.out.println?
return
This question already has answers here:
Closed 12 years ago.
Possible Duplicates:
Where/what level should logging code go?
Debug Levels
Is there a convention, a standard, or a widely used guide which will help with logging in Java? Specifically, what to include at each level (verbose, debug, ... etc.) rather than the actual mechanism of logging.
There are many guides out there of what to include at each log level, but none of them are specific; they're all vague, and this makes it hard to "follow orders".
Any tips would be appreciated.
It's subject to personal interpretation, but mine is (in order from finest to coursest):
Trace - The finest logging level. Can be used to log very specific information that is only relevant in a true debugging scenario, e.g., log every database access or every HTTP call etc.
Debug - Information to primary help you to debug your program. E.g., log every time a batching routine empties its batch or a new file is created on disk etc.
Info - General application flow, such as "Starting app", "connecting to db", "registering ...". In short, information which should help any observer understand what the application is doing in general.
Warn - Warns of errors that can be recovered. Such as failing to parse a date or using an unsafe routine. Note though that we should still try to obey the fail fast principle and not hide e.g., configuration errors using warning message, even though we a default value might be provided by the application.
Error - Denotes an often unrecoverable error. Such as failing to open a database connection.
Fatal/Critical Used to log an error the application cannot recover from, which might lead to an immediate program termination.
In the end it's up to you to define what suits you best. Personally, I run most production system with logging level of Info, where I'm mostly interested in following the applications main logic, and of course catch all warnings/errors.
Except for code cluttering, there is no such thing as too much logging. All logging which helps you reproduce or understand problems better are good logging. On a performance note, most logging systems (e.g., log4j) allows configuring which level to actually append to the physical log which is a great thing.
For what it's worth, we're using the following log levels:
DEBUG level messages give highly-detailed and/or specific information, only useful for tracking down problems.
INFORMATION messages give general information about what the system is doing. (e.g. processing file X)
WARNING messages warn the user about things which are not ideal, but should not affect the system. (e.g. configuration X missed out, using default value)
ERROR messages inform the user that something has gone wrong, but the system should be able to cope. (e.g. connection lost, but will try again)
CRITICAL messages inform the user when an un-recoverable error occurs. (i.e. I am about to abort the current task or crash)
I think the most important thing with log levels is to figure out a scheme, document it, and stick with it. Although making log level consistent between programs would be nice, as long as you've used common sense in defining your log levels, users will tolerate a certain amount of variance between programs.
Simple log what yuo think is important if you were to come back later and need to read the logs. This of course means that your Object.toStrings now need to be nice and readable and not a dump of crap thats impossible to read. This also means you need to do sensible things like quoting strings etc..