One thing I didn’t notice until now is that this is a superset of
distributed trace logging. Would you say that’s accurate?
On Mon, Jun 11, 2018 at 00:54, Apache <ralph.go...@dslextreme.com> wrote:
> One thing I forgot to mention. Although Log4J audit doesn’t make use of
> the product or category the catalog’s usefulness really comes into play
> when you want to create a UI to query and display the audit events. In that
> case associating events with products and/or categories can be quite
> helpful.
>
> Ralph
>
> > On Jun 10, 2018, at 1:36 AM, Apache <ralph.go...@dslextreme.com> wrote:
> >
> > Oh. You don’t have the maven plugin. Since it hasn’t been released yet
> you will have to build the Log4J audit project.
> >
> > Sent from my iPad
> >
> >> On Jun 10, 2018, at 12:23 AM, Remko Popma <remko.po...@gmail.com>
> wrote:
> >>
> >> 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
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >
> >
> >
>
>
> --
Matt Sicker <boa...@gmail.com>
