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>
