Is there a way of debugging JSF + PrimeFaces applications by simply looking at one log file? To be more specific, here is how I personally do it at the moment if something doesn't work as expected:
Look for visual indicator on the Web page (e.g. if I receive HTTP 500 obviously something is wrong)
I look in the log file of my application server for any warnings, errors or stacktraces
I look in the Firebug's network console to see if there were any errors in the HTTP response; this tends to happen from time to time (and it's not shown in the log!)
I check if it is a validation error by including a p:message on the form and display it.
For me, checking for errors is a 4-step workflow. Is there a better way of doing this? Ideally, it would be great if all these errors could be logged to a single log. Is this DIY or there is some standard way of doing it?
Thanks!
There is nothing out of box that will give you what you describe because these are all situations that occur on different layers.
This is typically because an unhandled exception made its way up the call stack. If you improve your code for exception handling then these circumstances should be caught and logged.
Improved exception handling and logging at all application layers will help capture all errors and exceptions in a single log file on the application server.
Firebug catches network errors in asynchronous postbacks as well as Javascript exceptions. This is completely a client side concern as the server just derives the markup. It might be possible to catch all Javascript exceptions before they are propagated up to Firebug and to send an asynchronous error report to the server for the server to log. This shouldn't be too terribly difficult to implement.
Again, better logging in your validator methods will be able to put this information in the application server logs so that you have all of this information in one place.
The bottom line is that these are all situations where they become a non-issue for developers who learn how to intuitively include good Instrumentation code throughout their applications.
There is also <p:log /> that lets you use PrimeFaces debug.
See: http://www.primefaces.org/showcase/ui/misc/log.xhtml
Hi i am also developing an application using jsf and primefgaces. I also had faced this problem earlier. Now i am using log4j to log all the errors/exceptions/ doubts into a single file. It is also very easy to use it.You can have a look at it, it may solve your problems.
Related
I'd like to find redundant blocks of code in my service. Is there a way to check when that last time this code was used runtime? The service is running on GCP.
I don't think there's a great solution to your problem but you could instrument, perhaps via Aspect-Oriented Programming (AOP), selected places in your code with simple logging statements and then monitor those.
You should avoid including any "hot code" which is executed very frequently because you can slow down your service and produce an overwhelming amount of logs (harder to manage and costly).
There's a lot of way to do this, but personally, I would use logging into this function and then let this app running normally. Then, you'll just have to check you log files and check for your logging message occurrences.
However, I'm not sure if it is possible to get this information without any action of your part to see previous usages of your code block.
Is there a way to be notified of caught exceptions in an eclipse application?
I know that if I start an application using eclipse debugger, I can suspend execution upon caught and uncaught exceptions (see https://stackoverflow.com/a/3066280/228965). I guess this feature somehow uses JVMTI.
Now I have the following problem:
I have an eclipse application not written by me. I want to monitor this application. I have written some bundles to monitor different aspect of the application (user interactions, workbench changes, etc..). I start these bundles along the application using bundles.info file. Now I need to be notified whenever an exception happens. I added a listener to error log and this way I am notified of uncaught exceptions. However I want also to be able to be notified of "any" exception, even those that have been caught by the original developers.
Is there a way to achieve this?
You could investigate the logger of your application. If it use log4j, you could create an appender specific for exceptions and work with them.
Add a breakpoint to the constructors of java.lang.Exception (or maybe even Throwable, depending upon exactly what you're looking for).
All exceptions, even custom ones, must extend from one of these, so you can find each Exception as it is being created - and then even trace it through to see where it is being caught and handled (if at all).
Using AOP may also be a good option, but this approach doesn't require any modifications to the existing code - source code or byte code.
From JDK 1.5 you can use Thread.setDefaultUncaughtExceptionHandler() for exactly this purpose.
I m in a project which my co-workers want to use log4cpp, log4php or log4j for flow control, ie: they want to log things, parse it and then flow control based on that information.
I told them that log4X should only be used to log, report errors and run time information.
How can I convince them not to use log4cpp or log4php or any log4x for flow control?
or do you think there is nothing wrong with this?
Sounds like a classic case of using the wrong tool for the job. There are many ways to do flow control and even whole servers for that purpose. Mule, IBM Message Broker to name a couple. As you say, LogX is for logging. The concept of trying to base the flow of messages, execution or whatever on the parsed output of a logger is so far wrong I cannot even begin to figure out why anyone would suggest such as bad idea, never mind adopt it. And there are so many ways to screw it up too. Never mind the fact of how do they intend to do real logging if their logging framework is not being used for it.
It never ceases to amaze me how often people in IT manage to make such decisions.
i am currently working on a java application for some network monitoring tool. In my code i am supposed to use logging a lot. Since its a network management software, the information in logs is quite useful to the user hence its compulsory to use them. But now I am bit confused with what kind of logger method i should prefer. Right now i am using Logger.lop(...//...) since with its help we are also logging the class name and method so its becoming very easy for me (developers) to debug the code and find the error. But finally I am confused should i deliver it to the end user with the same logging mechanism??? Is it any harm to let your user know what kind of class is executing currently , in which method error has occured. I have seen many times in many product in exception handling stacktrace is used so normally we get class name as well. So is there is no problem to let enduser know what your class name and method is??
Before considering the security implications of it, consider the performance. In most logging systems, getting the actual classname and method name dynamically by the logging facility requires reflection and dramatically slows down the logging - usually a synchronous operation. My guess is that in a network monitoring application, you really don't want that.
If you're hard-coding the method name into the log message (either by making it part of the message or by the category), that's a different story. As a security person, I don't consider it to be that big of a deal - if your code is in Java, it can be reversed anyhow, so your code should operate in such a way that it would be secure even if the code was given away.
All that being said, you could either use a different logging configuration for development and production, or those fine-grained messages could go in debug, trace, etc. If you're using log4j, it's generally advisable to use isDebugEnabled to wrap any logging statements which include anything dynamically-calculated as those get calculated before the logging statement determines whether it's enabled.
log4j/logback/slf4j allow you to have different formats for different appenders. For development you can enable a console appender where you include the class name in the format, while for the end-users you can omit it (for a file appender)
It's worth mentioning that such logging is performance costly in Java, contrary to C++ where it is usually implemented with preprocessor. Fortunately, with log4j/logback you can switch it on and off — follow Bozho's advice.
I'm using the Enerjy (http://www.enerjy.com/) static code analyzer tool on my Java code. It tells me that the following line:
System.err.println("Ignored that database");
is bad because it uses System.err. The exact error is: "JAVA0267 Use of System.err"
What is wrong with using System.err?
Short answer: It is considered a bad practice to use it for logging purposes.
It is an observation that in the old times when there where no widely available/accepted logging frameworks, everyone used System.err to print error messages and stack traces to the console. This approach might be appropriate during the development and local testing phase but is not appropriate for a production environment, because you might lose important error messages. Because of this, in almost all static analysis tools today this kind of code is detected and flagged as bad practice (or a similarly named problem).
Logging frameworks in turn provide the structured and logical way to log your events and error messages as they can store the message in various persistent locations (log file, log db, etc.).
The most obvious (and free of external dependencies) hack resolution is to use the built in Java Logging framework through the java.util.logging.Logger class as it forwards the logging events to the console by default. For example:
final Logger log = Logger.getLogger(getClass().getName());
...
log.log(Level.ERROR, "Something went wrong", theException);
(or you could just turn off that analysis option)
the descriptor of your error is:
The use of System.err may indicate residual debug or boilerplate code. Consider using a
full-featured logging package such as Apache Commons to handle error logging.
It seems that you are using System.err for logging purposes, that is suboptimal for several reasons:
it is impossible to enable logging at runtime without modifying the application binary
logging behavior cannot be controlled by editing a configuration file
problably many others
Whilst I agree with the points above about using a logging framework, I still tend to use System.err output in one place: Within shut-down hooks. This is because I discovered that when using the java.util.logging framework log statements are not always displayed if they occur in shut-down hooks. This is because the logging library presumably contains its own shutdown hook to clean up log files and other resources, and as you can't rely on the order in which shutdown hooks run, you cannot rely on java.util.logging statements working as expected.
Check out this link (the "Comments" section) for more information on this.
http://weblogs.java.net/blog/dwalend/archive/2004/05/shutdown_hooks_2.html
(Obviously the other alternative is to use a different logging framework.)
System.err is really more for debugging purposes than anything else. Proper exception handling and dealing with errors in a manner that is more user-friendly is preferred. If the user is meant to see the error, use a System.out.println instead.
If you want to keep track of those errors from a developer's standpoint, you should use a logger.
Things written to System.err are typically lost at runtime, so it is considered a better practice to use a logging framework that is more flexible about where to output the message, so it can be stored as a file and analyzed.
System.err and System.out for non-console applications is only ever seen by the developer running the code in his or her IDE, and useful information may get lost if the item is triggered in production.
System.err.println and System.out.println should not be used as loggging-interface. STD-Output and STD-Error (these are written by System.out and .err) are for messages from command-line-tools.
System.err prints to the console. This may be suitable for a student testing their homework, but will be unsuitable for an application where these messages won't be seen (Console only store so many lines).
A better approach would be to throw an exception holding the message that would normally get sent to the console. An alternative to this would be use third party logging software which would store this messages in a file which can be stored forever.