LogView is an application log reporting and manipulation tool for the enterprise level. It is aimed specifically at Java Developers, J2EE administrators, and JSP developers, however, there's no reason why it can't be used by someone not fitting those specifications.
LogView appears to be entering a largely empty market. The major alternatives are either to use a database reporting tool, like Crystal Reports or Discoverer(?), or to use a web-log analysis tool, like Analog or Webalizer. These are both insufficient for an enterprise level system.
The database reporting tools lack the ability to easily interact with your systems, they act at too low a level, that is at the database level and not at the application level, and they do not capitalize on existing Java skills. They lack platform independence, and replace it with high prices.
The web-log analysis tools are focused entirely on web servers. Yes some of them have been tweaked to handle Oracle databases, or FTP logs, but in general they are concerned with a log file consisting of web 'hit' data, and are outputting to a html webpage. There's little thought to having a dynamic application log reporter, or a command line output. If the data is coming from a database or a csv file, you're out of luck and have to find yet another tool.
LogView is generic at all ends and in the middle. It is designed to output to any format and to get its initial input from any data source. It is based on a simple chaining concept and Java developers can plug their own parts into the system with little effort.
LogView is written in Java2, so it will run on most systems. If the need arises it can be easily modified to run on a Java 1 system, which should add in a host of mobile phones and PDAs, but that need doesn't seem to be very high at the moment. More likely a WML output will be defined. It is open source, so feel free to port it to the language of your choice.
LogView is based on a collection of Java interfaces. The central design has very little in the way of concrete classes. This helps to make a system extremely pluggable. Here is a design document that shows the original basic idea. Things have grown since, but it still holds true.
This is likely to be a common question. XML is a great tool for translating between systems. In something like Jabber it makes a lot of sense as it allows a distributed system to easily evolve. In a Java framework it makes more sense to make XML optional everywhere, but to not build the system on XML's lackings.
Two options available, a .jar containing the class files and a .zip containing the java source files.
There are three options to using LogView.
The Taglib is in the works, and the Command line is on the todo list.
This is outside of the scope of LogView. I recommend the usage of the Apache Log4J package, and the Jakarta Taglib for Log4J. LogView will have code added to make it interact with these particular packages in the future.
Why not look at: Sample Html output to see the output of an apache web log, passed through a set of loglets to show the top 20 ip addresses by visit to my generationjava website. Over a particular unspecified period. Obviously there's a lot more to work on in the presentation department.
Well, the basic structure is laid down now, so here's a simple list.
Lastly, here's a snapshot of the latest version of the PLAN.