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
>>>>>
>>>>
>>>>
>>>>
>>>
>
>
>
