Really? I would think almost everything would want to track who made what
change to the system.
Ralph
> On Jun 11, 2018, at 5:20 AM, Matt Sicker <boa...@gmail.com> wrote:
>
> Ok, thanks for the clarification. It sounded far more advanced, and I’m
> getting a better picture here. I’ve never worked in a domain that requires
> auditing before.
>
> On Mon, Jun 11, 2018 at 08:03, Apache <ralph.go...@dslextreme.com> wrote:
>
>> No. It implements that feature through the request context but I wouldn’t
>> use a catalog for simple trace logging.
>>
>> Ralph
>>
>>> On Jun 11, 2018, at 4:29 AM, Matt Sicker <boa...@gmail.com> wrote:
>>>
>>> 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>
>>
>>
>> --
> Matt Sicker <boa...@gmail.com>
