This is the third blog in a series that's loosely looking at tracking application errors. In this series I’m writing a lightweight, but industrial strength, application that periodically scans application log files, looking for errors and, if any are found, generates and publishes a report.
If you’ve read the first blog in the series you may remember that I initially said that I needed a Report class and that “if you look at the code, you won’t find a class named Report, it was renamed Results and refactored to create a Formatter interface, the TextFormatter and HtmlFormatter classes together with the Publisher interface and EmailPublisher class”. This blog covers the design process, highlighting the reasoning behind the refactoring and how I arrived at the final implementation.
If you read on, you may think that the design logic given below is somewhat contrived. That’s because it is. The actual process of getting from the Report class to the Results class, the Formatter and Publisher interfaces together with their implementations probably only took a few seconds to dream up; however, writing it all down took some time. The design story goes like this...
Java tips, observations, bugs and problems from the world of Spring, Weblogic, Oracle, MySQL and many other technologies...
Wednesday, 26 March 2014
Tuesday, 11 March 2014
Tracking Exceptions With Spring - Part 2 - Delegate Pattern
In my last blog, I started to talk about the need to figure out whether or not your application is misbehaving in it's production environment. I said that one method of monitoring your application is by checking its log files for exceptions and taking appropriate action if one is found. Obviously, log files can take up hundreds of megabytes of disk space and it's impractical and really boring to monitor them by hand.
I also said that there were several ways of automatically monitoring log files and proposed a Spring based utility that combs log files daily and sends you an email if / when it finds any exceptions.
I only got as far as describing the first class: the FileLocator, which will search a directory and it's sub-directories for log files. When it finds one, it passes it to the FileValidator.
I also said that there were several ways of automatically monitoring log files and proposed a Spring based utility that combs log files daily and sends you an email if / when it finds any exceptions.
I only got as far as describing the first class: the FileLocator, which will search a directory and it's sub-directories for log files. When it finds one, it passes it to the FileValidator.
Labels:
Delegate,
Delegate Pattern,
Java,
Pattern,
Spring,
Validation,
Validator
Monday, 3 March 2014
Tracking Application Exceptions With Spring
A few weeks ago a colleague asked me to spend a week doing a support role as he needed cover whilst he took a well earned holiday and he couldn't find anyone else. As I'd just completed a particularly complex coding project and was feeling a little burnt out, I said 'yes'; after all the change would do me good.
Part of the job consisted of monitoring a collection of fairly critical backed processes, to see how well they were performing and whether or not they were going wrong.
We developers spend a lot of time and energy adding logging to our application in order to prove that it's working okay and to figure out what went wrong when an exception occurs. These log files are often used to tell us how well, or badly, our application is performing on a daily basis.
There are at least three ways of monitoring log files:
Part of the job consisted of monitoring a collection of fairly critical backed processes, to see how well they were performing and whether or not they were going wrong.
We developers spend a lot of time and energy adding logging to our application in order to prove that it's working okay and to figure out what went wrong when an exception occurs. These log files are often used to tell us how well, or badly, our application is performing on a daily basis.
I'm ignoring other techniques such as adding probes to your application by whatever method you choose, such as HTTP or JMX. These provide immediate information on your application rather than the second level monitoring under discussion here.
There are at least three ways of monitoring log files:
Subscribe to:
Posts (Atom)