Repository: logging-log4j-audit
Updated Branches:
  refs/heads/master 3ba2b5963 -> f7867e83d


Add the first README


Project: http://git-wip-us.apache.org/repos/asf/logging-log4j-audit/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/logging-log4j-audit/commit/f7867e83
Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j-audit/tree/f7867e83
Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j-audit/diff/f7867e83

Branch: refs/heads/master
Commit: f7867e83d61aeb5f6a7d03a95dc3ca4aebafa84b
Parents: 3ba2b59
Author: Ralph Goers <[email protected]>
Authored: Sat Sep 2 23:36:02 2017 -0700
Committer: Ralph Goers <[email protected]>
Committed: Sat Sep 2 23:36:02 2017 -0700

----------------------------------------------------------------------
 README.md | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/logging-log4j-audit/blob/f7867e83/README.md
----------------------------------------------------------------------
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..6ca273b
--- /dev/null
+++ b/README.md
@@ -0,0 +1,34 @@
+# Apache Log4j Audit 
+
+Log4j-Audit provides a framework for defining audit events and then logging 
them using Log4j. The framework focuses on 
+defining the events and providing an easy mechanism for applications to log 
them, allowing products to provide 
+consistency and validity to the events that are logged. It does not focus on 
how the log events are written to a
+data store. Log4j itself provides many options for that.
+
+The expected process is that business analysts or product managers will be 
managing the catalog, defining the events
+and attributes so that consumers of the events will have a consistent 
experience. For example, instead of one event
+using an attribute with a name of "custAddr" and another using a name of 
"customerAddress", both would use the same
+name for attributes that have the same meaning. 
+
+Once the catalog is modified in the web application it is saved as JSON to a 
git repository. It is expected that 
+a continuous integration system would notice the change and start a build of 
that project. The build would use the 
+Log4j Audit Maven Plugin to generate Java interfaces that Java developers 
would use to implement the audit logging
+within the application. Non-Java applications would call the Audit Service by 
sending an appropriate Data Transfer
+Object in JSON form and the Audit Service would perform the same validation 
that logging via the Java Interface
+would.
+
+## Packages
+
+### Log4j Audit
+
+The Log4j Audit module contains the Log4j Audit API that Java application 
leverage to perform audit logging, the
+Log4j Audit Maven Plugin that generates Java Interfaces from the catalog, and 
the Audit Service that non-Java 
+applications interact with to perform audit logging. The Audit service will 
also provide access to define 
+dynamic catalog entries for systems that allow new custom objects and 
attributes to be created while the application 
+is executing and need to audit when actions are taken against these objects. 
+
+### Log4j Catalog 
+
+The Log4j Catalog module contains the API for working with the catalog, a 
module for persisting the catalog using 
+the Java Persistence Architecture (JPA), a module for reading and writing the 
JSON version of the catalog to a remote
+GIT repository, and a module that provides a web application that can edit the 
various components of the catalog.
\ No newline at end of file

Reply via email to