Tracking Exceptions - Part 6 - Building an Executable Jar

If you’ve read the previous five blogs in this series, you’ll know that I’ve been building a Spring application that runs periodically to check a whole bunch of error logs for exceptions and then email you the results.

Having written the code and the tests, and being fairly certain it’ll work the next and final step is to package the whole thing up and deploy it to a production machine. The actual deployment and packaging methods will depend upon your own organisation's processes and procedures. In this example, however, I’m going to choose the simplest way possible to create and deploy an executable JAR file. The first step was completed several weeks ago, and that’s defining our output as a JAR file in the Maven POM file, which, as you’ll probably already know, is done using the packaging element:

Tracking Exceptions - Part 5 - Scheduling With Spring

It seems that I'm finally getting close to the end of this series of blogs on Error Tracking using Spring and for those who haven’t read any blogs in the series I’m writing a simple, but almost industrial strength, Spring application that scans for exceptions in log files and then generates a report. From the first blog in the series, these were my initial requirements:

1. Search a given directory and its sub-directories (possibly) looking for files of a particular type.
2. If a file is found then check its date: does it need to be searched for errors?
3. If the file is young enough to be checked then validate it, looking for exceptions.
4. If it contains exceptions, are they the ones we’re looking for or have they been excluded?
5. If it contains the kind of exceptions we’re after, then add the details to a report.
6. When all the files have been checked, format the report ready for publishing.
7. Publish the report using email or some other technique.
8. The whole thing will run at a given time every day

This blog takes a look at meeting requirement number 8: "The whole thing will run at a given time every day" and this means implementing some kind of scheduling.

Tracking Exceptions - Part 4 - Spring's Mail Sender

If you've read any of the previous blogs in this series, you may remember that I'm developing a small but almost industrial strength application that searches log files for exceptions. You may also remember that I now have a class that can contain a whole bunch of results that will need sending to any one whose interested. This will be done by implementing my simple Publisher interface shown below.

public interface Publisher {

  public <T> boolean publish(T report);
}

If you remember, the requirement was:

7 . Publish the report using email or some other technique.

In this blog I’m dealing with the concrete part of the requirement: sending a report by email.

Error Tracking Reports - Part 3 - Strategy and Package Private

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...