That is with
C:\Users\remko\IdeaProjects\logging-log4j-audit-sample>mvn --version
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
2017-10-18T16:58:13+09:00)
Maven home: C:\apps\apache-maven-3.5.2\bin\..
Java version: 1.8.0_161, vendor: Oracle Corporation
Java home: C:\apps\jdk1.8.0_161\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
On Sun, Jun 10, 2018 at 4:21 PM, Remko Popma <remko.po...@gmail.com> wrote:
> getting this now
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Audit Sample Parent ................................ SUCCESS [
> 0.839 s]
> [INFO] audit-service-api .................................. FAILURE [
> 0.006 s]
> [INFO] audit-service-war .................................. SKIPPED
> [INFO] audit-service ...................................... SKIPPED
> [INFO] sample-app ......................................... SKIPPED
> [INFO] ------------------------------------------------------------
> ------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------
> ------------
> [INFO] Total time: 1.116 s
> [INFO] Finished at: 2018-06-10T16:11:08+09:00
> [INFO] Final Memory: 12M/245M
> [INFO] ------------------------------------------------------------
> ------------
> [ERROR] Plugin
> org.apache.logging.log4j:log4j-audit-maven-plugin:1.0.0-SNAPSHOT
> or one of its dependencies could not be resolved: Could not find artifact
> org.apache.logging.log4j:log4j-audit-maven-plugin:jar:1.0.0-SNAPSHOT ->
> [Help 1]
> [ERROR]
>
>
> On Sun, Jun 10, 2018 at 2:53 PM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
>
>> I finally have had time to take a breath and do something with this. I
>> have tried to incorporate many of your comments in the documentation. I
>> have updated my web site accordingly. Some comments are below.
>>
>> I really would like feedback on more than just the site as I need to
>> release this.
>>
>> > On May 7, 2018, at 5:42 PM, Remko Popma <remko.po...@gmail.com> wrote:
>> >
>> > I had time to look at this during the flight, here it is:
>> >
>> > ----
>> > index.html
>> >
>> > typo: Diagnostic logs are critical in aiding in maintaining the
>> > servicability -> critical in maintaining?
>> >
>> > Overall, the first three sections, "What is Audit Logging", What is the
>> > difference between audit logging and normal logging?" and "What is Log4j
>> > Audit?" are very good: give good overview of the purpose and don't
>> assume
>> > prior knowledge.
>> >
>> > From the "Features" section, the narrative changes perspective from what
>> > users would want to what Log4j Audit provides.
>> > I would add a few sentences to that transition, something like:
>> >
>> > {quote}
>> > (after Features)
>> > Each application has its own audit events. Before using Log4j Audit,
>> > applications need to define AuditMessages that capture the exact
>> attributes
>> > of its audit events. The [Getting Started](link) page provides a
>> tutorial
>> > that explains how to define audit events for an application.
>> >
>> > (after Audit Event Catalog header)
>> > Once audit events are defined, they need to be maintained: as the
>> > application evolves, developers will inevitably discover they need to
>> add,
>> > remove or change attributes of the audit events. Log4j Audit can persist
>> > the audit event definitions in a JSON file. This file becomes the Audit
>> > Event Catalog for the application. Log4j Audit is designed to store the
>> > event definition file in a Git repository so that the evolution of the
>> > audit events themselves have an audit trail in the Git history of the
>> file.
>> > Log4j Audit provides a web interface for editing the events.
>> >
>> > Log4j Audit uses the catalog of events to determine ... (continue with
>> > current text of Audit Event Catalog)
>> > {quote}
>> >
>> > Question about the Requirements section: it isn't clear to me (and
>> likely
>> > to other readers) why Dynamic Event Catalogs would require a database
>> > instead of one or more JSON files. Is that explained somewhere? Perhaps
>> > Dynamic Audit Events need a separate page or dedicated section
>> somewhere.
>> > The Getting Started page mentions "manage dynamic catalogs" in the
>> > paragraph under "What you will build" but I couldn't find anything on
>> the
>> > topic of dynamic catalogs.
>> >
>> >
>> >
>> > ----
>> > catalog.html
>> >
>> > From the first paragraph, I would remove "The events may be grouped by
>> > Products and/or Categories, but at this time nothing in Log4j Audit
>> makes
>> > use of the product or catalog definitions". The same sentences is
>> repeated
>> > at the bottom of the page and since this feature is not used it is
>> > confusing to me that the feature is so prominently mentioned in the
>> first
>> > paragraph of the page. I would consider removing this feature
>> altogether.
>> >
>> > Overall this is a very good page. Succinct but complete. Consider
>> moving it
>> > above RequestContext in the left-hand navigation menu.
>> >
>> >
>> >
>> > ----
>> > gettingStarted.html
>> >
>> > Overall, this page is only effective for people who actually perform the
>> > steps and execute the commands mentioned in the page.
>> >
>> > It would be good if the page would also be useful for people who only
>> read
>> > the page but don't actually perform the steps:
>> >
>> > * Can the page also show an example of an audit event in JSON format.
>> This
>> > could be a simple event with few attributes (maybe a login event?) or
>> the
>> > transfer event that is used later in the page.
>> > * I would also like to see the Java interface that is generated from
>> this
>> > JSON audit event.
>> > * Finally, I would like to see how my application would use this
>> generated
>> > Java interface. How do I get an instance, how do I populate the
>> attributes,
>> > and what do I do with the instance after I populated it?
>> >
>> > I'm sure the above is available in the source code of the sample
>> > application, but this page is a good place to show some of the
>> highlights
>> > of that source code with some explanatory text.
>> >
>> > Secondly, the page mentions remote audit logging and how the war file
>> > provides endpoints for remove audit logging. Is it worth dedicating a
>> > separate page to show how to configure end points for remote audit
>> logging?
>> >
>> > Finally, about the catalog screenshots: I understand that attributes are
>> > managed separately so they can be reused. The second screenshot shows
>> the
>> > billPay and deposit events. Are these events related to the transfer
>> event
>> > that is mentioned in the curl example in this page?
>>
>> These are events that take place in banking. billPay is paying a bill,
>> deposit is depositing money into an account, transfer moves money from one
>> account to another. I used these because many people understand these
>> concepts.
>>
>>
>> > I was trying to see how
>> > they could be related but couldn't figure it out.
>> > Also, what are the attributes for the billPay and deposit events?
>>
>> The attributes for these events are those shown in the “Assigned
>> Attributes” column. The request context attributes are available for all
>> events.
>>
>> > If the
>> > Catalog Editor has a screen to show the attributes that are part of an
>> > event then it may be good to add a screenshot for this (I guess this
>> would
>> > be the Edit Event screen) as well. That would tie all these concepts
>> > together.
>>
>> As I said, the attributes are on the screen that is shown. I would
>> suggest you perform the steps in the getting started so you can see for
>> yourself.
>> >
>> >
>> > ----
>> > requestContext.html
>> >
>> > typo: typcial -> typical
>> > typo: acrossall -> across all
>> > typo: datbase -> database
>> >
>> > About Mapping Annotations:
>> > This is still a bit abstract to me. Would it be possible to provide some
>> > more explanation on when applications should use ClientServer, when
>> Local,
>> > and when Chained annotations? Perhaps some example use cases? Or, if
>> > possible, tie this to the use case presented in the sample application
>> (if
>> > that makes sense)?
>>
>> I am not sure what more there is to say. Local means a value in the
>> request context is local to that server and should not be passed to called
>> services. ClientServer means that a value is passed from the current
>> application to services it calls. Chained means the value is associated
>> with one request context field on the current server but will be in a
>> different field in the called service. The example for chained is the
>> current hostname. The hostname request context field always contains the
>> host name of the current server. When calling a service the current host
>> name moves to the callingHost field so that the called service knows what
>> server called it.
>>
>> >
>> > About Transporting the RequestContext:
>> > Until now, the information was generically useful for all applications,
>> but
>> > this section is specifically useful for web applications.
>> > For people who don't work on web applications this transition may be a
>> bit
>> > jarring.
>> > Would it make sense for this section and the following two sections to
>> be
>> > moved to a separate page? Something like "Web Applications" or "Remote
>> > Audit Logging”?
>>
>> This concept applies to any kind of distributed application. For example,
>> with AMQP we do the exact same thing by copying the RequestContext fields
>> into AMQP headers and then repopulating the RequestContext when the message
>> is processed in the consumer. I have added text to describe this. I have
>> components that do this for my day job but I have not added them to
>> log4j-audi.
>>
>> >
>> > ----
>> > Remko
>> >
>>
>>
>>
>
