Re: [Flume] Integration with OpenTelemetry

[Ralph Goers]

This is a great post Matt!

Fluentbit, Fluentd, Logstash, and Filebeat are the main tools used for log 
forwarding. While they all have some amount of plugability none of the are as 
flexible as Flume. In addition, as I have mentioned before, none of them 
provide guaranteed delivery so I would never recommend them for forwarding 
audit logs. 

I have also previously explained my use case for using Flume, which is for 
forwarding Call Detail Records that start off as records in the Radius protocol 
[1] across data centers, which also requires guaranteed delivery. I wouldn’t be 
able to use any of those other tools to do that without significant 
modification.

I am all for supporting standards. If you can outline what you are proposing on 
a Confluence page I would wholeheartedly support it.

As you probably know, I started work on separating out things that I don’t 
consider to be “core” to Flume into separate repos. That work is only half 
completed. I would suggest that you consider whether what you are proposing 
also be in its own repo. As it is, the CI for Flume fails because the generated 
logs are exceeding the available disk space. In addition, the build takes a 
long time. 

Also, I have never really been a big fan of the configuration mechanism Flume 
uses. I was able to somewhat bypass it by implementing support for Spring Boot, 
but it would be great if the Log4j Plugin system could somehow be used to 
simplify configuring Flume for those who don’t want to use Spring boot. I know 
that is right up your alley.

Ralph


1. https://networkradius.com/doc/current/introduction/RADIUS.html

> On Nov 29, 2023, at 5:32 PM, Matt Sicker  wrote:
> 
> One of the main reasons why I supported Flume joining this PMC was that I 
> noticed it has significant overlap with projects in the observability space 
> despite not being advertised as such. For example, the project FluentBit is 
> extremely similar to Flume, but its main purpose is for collecting, 
> processing, forwarding, etc., logs, metrics, and traces (i.e., observability 
> data). FluentBit is not the only thing in this space, though it seems to be 
> fairly popular. These sorts of tools are used for ultimately publishing 
> observability data to one or more observability tools like Prometheus, 
> Splunk, Jaeger, Grafana, etc., and with a unified collector and processor, it 
> becomes possible to publish all your observability data into one tool rather 
> than three or more disparate tools (and the added operational costs of 
> storing tons of duplicated log data from three or more methods of generating 
> log data).
> 
> A project at the CNCF, OpenTelemetry, has become the sort of de facto 
> standard for interoperability in this space. In particular, they’ve published 
> the OTLP specification  for 
> general telemetry data delivery and the OpenTelemetry specification 
>  for various common APIs. While 
> I’m still researching in this space, I think it would be useful for Flume to 
> integrate with some of these APIs and SDKs (while other parts might be more 
> relevant in our logging libraries instead). There is also the Open Agent 
> Management Protocol  which is 
> still in beta status that might also be relevant here (and potentially 
> relevant in the logging libraries).
> 
> Supporting common standards for our projects seems like a useful thing to do, 
> and despite the popularity of some existing solutions there, I believe there 
> is plenty of space for us to contribute. I also think that this can provide 
> opportunity for the various components in this PMC to interoperate as these 
> specs are fairly language neutral with some sample versions in many different 
> languages.

[Flume] Integration with OpenTelemetry

[Matt Sicker]

One of the main reasons why I supported Flume joining this PMC was that I 
noticed it has significant overlap with projects in the observability space 
despite not being advertised as such. For example, the project FluentBit is 
extremely similar to Flume, but its main purpose is for collecting, processing, 
forwarding, etc., logs, metrics, and traces (i.e., observability data). 
FluentBit is not the only thing in this space, though it seems to be fairly 
popular. These sorts of tools are used for ultimately publishing observability 
data to one or more observability tools like Prometheus, Splunk, Jaeger, 
Grafana, etc., and with a unified collector and processor, it becomes possible 
to publish all your observability data into one tool rather than three or more 
disparate tools (and the added operational costs of storing tons of duplicated 
log data from three or more methods of generating log data).

A project at the CNCF, OpenTelemetry, has become the sort of de facto standard 
for interoperability in this space. In particular, they’ve published the OTLP 
specification  for general telemetry 
data delivery and the OpenTelemetry specification 
 for various common APIs. While I’m 
still researching in this space, I think it would be useful for Flume to 
integrate with some of these APIs and SDKs (while other parts might be more 
relevant in our logging libraries instead). There is also the Open Agent 
Management Protocol  which is still 
in beta status that might also be relevant here (and potentially relevant in 
the logging libraries).

Supporting common standards for our projects seems like a useful thing to do, 
and despite the popularity of some existing solutions there, I believe there is 
plenty of space for us to contribute. I also think that this can provide 
opportunity for the various components in this PMC to interoperate as these 
specs are fairly language neutral with some sample versions in many different 
languages.

Re: [chainsaw] Next steps? Or is it over?

[Christian Grobmeier]

Thank you Scott,
It is very encouraging you are joining this effort! Now I feel more confident 
we can make a new release!
I am doing my best to learn more about Chainsaw and contribute further!

On Wed, Nov 29, 2023, at 20:13, Scott Deboy wrote:
> I'll go through the UI and re-add small features that I think are
> critical but were lost in the log4j1-jettison effort.
>
> I'll follow-up in a new thread.
>
> Scott
>
>
> On 11/28/23, Scott Deboy  wrote:
>> I've fixed the logger tree split pane UI (left artifacts when you
>> drag), and I've added VFSLogFilePatternReceiver support and it works
>> fine.
>>
>> To test VFSLogFilePatternReceiver:
>> * Start Chainsaw
>> * View, Show Receivers menu
>> * Hit the 'create' icon in the receivers pane
>> * Select 'New VFSLogFilePatternReceiver'
>>
>> In the bottom section of the receivers pane, enter values for the
>> following attributes:
>>
>> fileURL - provide a local text file path (triple-slashes in the URI), like:
>> file:///Users/sdeboy/somefile.txt
>>
>> logFormat - just use a simple format for now:
>> MESSAGE
>>
>> tailing:
>> true
>>
>> * Click OK
>>
>> A new tab with the receiver name - default is 'Receiver' - will be
>> created and entries from the log file will be routed there.
>>
>> In a text editor, add some lines to the file and you'll see the new
>> lines appear in the bottom of the log table.
>>
>> Scott
>>
>>
>>
>> On 11/28/23, Christian Grobmeier  wrote:
>>> Hi Scott,
>>>
>>> I believe you; thanks for speaking up and being around.
>>>
>>> How can I help?
>>>
>>> I think Chainsaw needs to see a release soon, so what can I do to help
>>> you?
>>>
>>> I am glad to clean up things and whatever is necessary.
>>>
>>> Kind regards,
>>> Christian
>>>
>>> On Wed, Nov 29, 2023, at 00:15, Scott Deboy wrote:
 I have dropped the ball here, but will commit to working on this, this
 year.

 I want to preserve a bunch of what can be done in the
 https://github.com/apache/logging-chainsaw/tree/chainsaw-with-log4j1-dep
 branch, and some of that just isn't possible because equivalent
 functionality was never added to log4j2.

 Remote tailing via the VFSLogFilePatternReceiver, with the existing
 filter and search support, is enough I think.

 I'll jump in and help.

 Scott

 Scott

 On 11/28/23, Christian Grobmeier  wrote:
> Hello,
>
> I have started to clean up a few things that seemed good to me.
> The last time I sent a message like this was 1.5 months ago, but there
> was
> not much progress in maintaining it.
>
> I am currently in a state where I slowly get what should be happening,
> but
> unfortunately, it does not.
> We are not ready to release a new version, nor do we know what is
> necessary
> to release one.
>
> We have lots of dead code in Chainsaw, and it is tough to understand
> "what
> should it do?"
>
> I move around many Swing components to understand better, because the
> code
> is complex. However, I didn't see how Chainsaw would do anything
> beneficial.
> It's not working at all.
>
> Yes, I now what a "receiver" is meant to do. But apart from this
> description
> we have no specific goal nor do we actually receive anything (or I
> don't
> know how).
>
> For an ordinary person, it seems impossible to connect to a running
> server
> to tail a log file (I am not sure if it should do it) or even analyze a
> regular log file.
>
> This is when either old committers step up to tell a new one, like me,
> what
> is going on or to set a specific goal that we want to reach with a new
> version of Chainsaw.
>
> It was fun to clean up, but we need to talk more about Chainsaw. As for
> me,
> it is unusable, hard to fix and we need a new set of goals and radical
> refactoring to make it work again. If we are not agreeing on what it
> should
> do, it's time to go dormant. I am sorry to say this, I like Chainsaw.
> But
> me
> alone - I can't fix it.
>
> Please let me know,
> Christian
>
>
>>>
>>

Re: [chainsaw] Next steps? Or is it over?

[Scott Deboy]

I'll go through the UI and re-add small features that I think are
critical but were lost in the log4j1-jettison effort.

I'll follow-up in a new thread.

Scott


On 11/28/23, Scott Deboy  wrote:
> I've fixed the logger tree split pane UI (left artifacts when you
> drag), and I've added VFSLogFilePatternReceiver support and it works
> fine.
>
> To test VFSLogFilePatternReceiver:
> * Start Chainsaw
> * View, Show Receivers menu
> * Hit the 'create' icon in the receivers pane
> * Select 'New VFSLogFilePatternReceiver'
>
> In the bottom section of the receivers pane, enter values for the
> following attributes:
>
> fileURL - provide a local text file path (triple-slashes in the URI), like:
> file:///Users/sdeboy/somefile.txt
>
> logFormat - just use a simple format for now:
> MESSAGE
>
> tailing:
> true
>
> * Click OK
>
> A new tab with the receiver name - default is 'Receiver' - will be
> created and entries from the log file will be routed there.
>
> In a text editor, add some lines to the file and you'll see the new
> lines appear in the bottom of the log table.
>
> Scott
>
>
>
> On 11/28/23, Christian Grobmeier  wrote:
>> Hi Scott,
>>
>> I believe you; thanks for speaking up and being around.
>>
>> How can I help?
>>
>> I think Chainsaw needs to see a release soon, so what can I do to help
>> you?
>>
>> I am glad to clean up things and whatever is necessary.
>>
>> Kind regards,
>> Christian
>>
>> On Wed, Nov 29, 2023, at 00:15, Scott Deboy wrote:
>>> I have dropped the ball here, but will commit to working on this, this
>>> year.
>>>
>>> I want to preserve a bunch of what can be done in the
>>> https://github.com/apache/logging-chainsaw/tree/chainsaw-with-log4j1-dep
>>> branch, and some of that just isn't possible because equivalent
>>> functionality was never added to log4j2.
>>>
>>> Remote tailing via the VFSLogFilePatternReceiver, with the existing
>>> filter and search support, is enough I think.
>>>
>>> I'll jump in and help.
>>>
>>> Scott
>>>
>>> Scott
>>>
>>> On 11/28/23, Christian Grobmeier  wrote:
 Hello,

 I have started to clean up a few things that seemed good to me.
 The last time I sent a message like this was 1.5 months ago, but there
 was
 not much progress in maintaining it.

 I am currently in a state where I slowly get what should be happening,
 but
 unfortunately, it does not.
 We are not ready to release a new version, nor do we know what is
 necessary
 to release one.

 We have lots of dead code in Chainsaw, and it is tough to understand
 "what
 should it do?"

 I move around many Swing components to understand better, because the
 code
 is complex. However, I didn't see how Chainsaw would do anything
 beneficial.
 It's not working at all.

 Yes, I now what a "receiver" is meant to do. But apart from this
 description
 we have no specific goal nor do we actually receive anything (or I
 don't
 know how).

 For an ordinary person, it seems impossible to connect to a running
 server
 to tail a log file (I am not sure if it should do it) or even analyze a
 regular log file.

 This is when either old committers step up to tell a new one, like me,
 what
 is going on or to set a specific goal that we want to reach with a new
 version of Chainsaw.

 It was fun to clean up, but we need to talk more about Chainsaw. As for
 me,
 it is unusable, hard to fix and we need a new set of goals and radical
 refactoring to make it work again. If we are not agreeing on what it
 should
 do, it's time to go dormant. I am sorry to say this, I like Chainsaw.
 But
 me
 alone - I can't fix it.

 Please let me know,
 Christian


>>
>

Re: [log4j] Unstable tests on Windows

[Matt Sicker]

There’s a JUnit annotation `@Issue` or something like that (Spock has a similar 
annotation) which you can use for linking to an issue. Otherwise, adding `@Tag` 
annotations allows for arbitrary tags (of which we use several already such as 
“functional” and “sleepy”).

> On Nov 28, 2023, at 5:55 AM, Gary Gregory  wrote:
> 
> I think JUnit can group tests in categories with annotations (AFK).
> 
> Gary
> 
> On Tue, Nov 28, 2023, 12:01 AM Ralph Goers 
> wrote:
> 
>> I would be -1 if the issues are going to be ignored or not tracked in any
>> way. I don’t know if GitHub has something like a Jira Epic or if they can
>> be tagged in some way so that they can be easily located but something like
>> that would be fine. Even tracking them in Confluence would be fine.
>> 
>> It would also be great if only the failing tests could be run under a
>> profile making it easy to fix them.
>> 
>> Hopefully you get what I mean. I am not looking for something complicated,
>> just a way to make it easy to find them when someone has the urge to fix
>> them.
>> 
>> Ralph
>> 
>>> On Nov 27, 2023, at 3:28 AM, Volkan Yazıcı  wrote:
>>> 
>>> Ralph did not agree, but did not strongly object either. Ralph, are you
>> -1
>>> on disabling tests only Windows that are failing frequently on Windows
>> and
>>> capturing them in tickets to be addressed?
>>> 
>>> On Thu, Nov 23, 2023 at 12:23 AM Christian Grobmeier <
>> grobme...@apache.org>
>>> wrote:
>>> 
 Ralph said, nobody would ever fix these tests if you do it like this. I
 think you should create the ticket but keep the tests until we find the
 issue. Otherwise there issues will rot
 
 On Wed, Nov 22, 2023, at 09:13, Volkan Yazıcı wrote:
> AFAIC, nobody[1] shows a strong opposition against the idea of
>> disabling
> frequently failing Windows tests only on Windows and creating a ticket
 for
> each one. I will proceed with that.
> 
> [1] Except Piotr, whom I discussed the issue with in Slack and he
>> agreed
> with the above shared approach.
> 
> On Mon, Nov 20, 2023 at 12:57 PM Volkan Yazıcı  wrote:
> 
>> I am not asking to disable Windows tests. I am asking to disable tests
>> and only those tests that have a failure rate on Windows higher than,
>> say, 30%. To be precise, I think there are 2-3 of them dealing with
>> network sockets and rolling file appenders. I am not talking about
>> dozens or such.
>> 
>> After disabling them, we can create a ticket referencing them. So that
>> interested parties can fix them.
>> 
>> On Mon, Nov 20, 2023 at 12:25 PM Piotr P. Karwasz
>>  wrote:
>>> 
>>> Hi Volkan,
>>> 
>>> On Mon, 20 Nov 2023 at 09:36, Volkan Yazıcı  wrote:
 
 As Gary (the only Windows user among the active Log4j maintainers,
 AFAIK) has noticed several times, Log4j tests on Windows are pretty
 unstable. It not only fails on Gary's laptop, but Piotr and I need
 to
 give Windows tests in CI a kick on a regular basis. Approximately
 one
 out of three CI runs fails on Windows. Piotr already improved the
 situation extensively, though there are still several leftovers that
 need attention.
 
 Unless somebody steps up to improve the unstable Windows tests, I
 would like to disable those only for the WIndows platform.
>>> 
>>> Please don't. Windows has an annoying file locking policy that
>>> prevents users from deleting files with open file descriptors, but
>>> that is one of the few ways to detect resource leakage we have.
>>> 
>>> Tests running on *NIXes will ignore problems with open file
>>> descriptors and delete the log files, but on a production system
>> those
>>> leaks will accumulate and cause application crashes. We had such a
>>> leak, when we used `URLConnection#getLastModified` on a `jar:...`
>> URL.
>>> This call caused file descriptor exhaustion on both Windows and
>>> *NIXes, but only the Windows test was able to detect it.
>>> 
>>> Piotr,
>>> who never thought would ever defend Microsoft Windows.
>>> 
>>> PS: Gary reports the failures, but always runs the build again until
>>> it succeeds, even on Friday 13th, when he had to wait until Saturday
>>> 14th for the test run to succeed.
>> 
 
>> 
>> 

Re: [log4j] Releasing Log4j `3.0.0`

[Matt Sicker]

I’m good with a beta release to come soon. I’m still working on a branch to fix 
up the remaining SPI updates to avoid guessing at ClassLoaders, but that isn’t 
required for a beta release. As for the branches, if 2.x was made into 3.0, 
then main would be 4.0, and where would that leave us? Back in the same debate. 
I suggest you look at the main branch more closely.

> On Nov 28, 2023, at 4:19 AM, Volkan Yazıcı  wrote:
> 
> I plan to work on `main` until February, finalize recycler implementation,
> carry out whatever improvement I can, and release `3.0.0`.
> 
> *If you have any objections with this plan, or if you have things to do on
> `main` and you cannot comply with this schedule, etc., let's discuss.* I
> want to agree on a plan and timeline that works for you.
> 
> *Personal remark:* I am against releasing `3.0.0` from `main`. `2.x`
> changes that didn't go into `main` are titanic. `main` also contains
> several incomplete code, doc, or both. I support the idea of forking `3.x`
> from `2.x`, backporting crucial features from `main` to `3.x`, and then
> releasing `3.0.0`. I had several email, Slack, and video conversations with
> Ralph, Matt, and Piotr. They don't agree with me. Ralph even threatened to
> veto all non-bugfix changes on `2.x`
> . I am
> outnumbered and I accept the defeat. Let's release `3.0.0` from `main` and
> move on. I don't want to spend time discussing this subject further.

Re: Optional dependencies and JPMS

[Matt Sicker]

Small changes to that:

* Should move the XML configuration format to its own module, too, for the 
java.xml dependency
* Should remove the Jackson JSON configuration format as we have a 
dependency-free JSON format in core (the YAML format support is based on the 
Jackson JSON support, so this code can be simplified to only supporting YAML)

> On Nov 29, 2023, at 5:49 AM, Piotr P. Karwasz  wrote:
> 
> Hi all,
> 
> I have been using a modularized sandbox project to test Log4j and
> optional dependencies are a nightmare.
> 
> Small example: if I use Log4j API in my project and I add:
> 
> requires org.apache.logging.log4j;
> 
> then when I run the app, the JVM will automatically add `log4j-api` to
> the boot layer.
> 
> It will also add `log4j-core`, since it provides a service that
> `log4j-api` uses.
> 
> However it will **not** load `jackson-datatype-yaml`, because it is an
> **optional** dependency of `log4j-core` and provides no services
> `log4j-core` is interested in. The user must go to the additional pain
> of specifying `--add-modules` or the application developer must add a
> bogus `requires` statement.
> 
> Therefore I would propose to:
> 
> * move the YAML configuration factory to a separate module and delete
> one of the JSON configuration factories (the one that uses Jackson).
> 
> What do you think?

Re: Optional dependencies and JPMS

[Gary Gregory]

I can tell you that some people I work with would use property files for
everything under the sun if they could...

Gary

On Wed, Nov 29, 2023, 9:29 AM Ralph Goers 
wrote:

> I agree with this. IMO the only configuration syntaxes we should support
> are those we can implement with no dependencies. At the moment that is JSON
> and Properties (Ugh!). I would love to deprecate properties but I know that
> is a non-starter since we didn’t support them for years and were constantly
> asked for it.
>
> Ralph
>
> > On Nov 29, 2023, at 5:14 AM, Gary Gregory 
> wrote:
> >
> > I think the overall goal should be to have no optional dependencies, no
> > surprises. I personally hope to never force YAML on anyone.
> >
> > Gary
> >
> > On Wed, Nov 29, 2023, 6:51 AM Piotr P. Karwasz 
> > wrote:
> >
> >> Hi all,
> >>
> >> I have been using a modularized sandbox project to test Log4j and
> >> optional dependencies are a nightmare.
> >>
> >> Small example: if I use Log4j API in my project and I add:
> >>
> >> requires org.apache.logging.log4j;
> >>
> >> then when I run the app, the JVM will automatically add `log4j-api` to
> >> the boot layer.
> >>
> >> It will also add `log4j-core`, since it provides a service that
> >> `log4j-api` uses.
> >>
> >> However it will **not** load `jackson-datatype-yaml`, because it is an
> >> **optional** dependency of `log4j-core` and provides no services
> >> `log4j-core` is interested in. The user must go to the additional pain
> >> of specifying `--add-modules` or the application developer must add a
> >> bogus `requires` statement.
> >>
> >> Therefore I would propose to:
> >>
> >> * move the YAML configuration factory to a separate module and delete
> >> one of the JSON configuration factories (the one that uses Jackson).
> >>
> >> What do you think?
> >>
>
>

Re: Optional dependencies and JPMS

[Ralph Goers]

FWIw, the situation you describe isn’t really any different than it is with 
Maven. If I declare an optional dependency in a component it will not be 
automatically included. A user has to add it to their pom.xml as a required 
dependency for it to be included. That is really no different than a user 
having to add a requires statement to their module-info file.

Ralph

> On Nov 29, 2023, at 7:29 AM, Ralph Goers  wrote:
> 
> I agree with this. IMO the only configuration syntaxes we should support are 
> those we can implement with no dependencies. At the moment that is JSON and 
> Properties (Ugh!). I would love to deprecate properties but I know that is a 
> non-starter since we didn’t support them for years and were constantly asked 
> for it.
> 
> Ralph
> 
>> On Nov 29, 2023, at 5:14 AM, Gary Gregory  wrote:
>> 
>> I think the overall goal should be to have no optional dependencies, no
>> surprises. I personally hope to never force YAML on anyone.
>> 
>> Gary
>> 
>> On Wed, Nov 29, 2023, 6:51 AM Piotr P. Karwasz 
>> wrote:
>> 
>>> Hi all,
>>> 
>>> I have been using a modularized sandbox project to test Log4j and
>>> optional dependencies are a nightmare.
>>> 
>>> Small example: if I use Log4j API in my project and I add:
>>> 
>>> requires org.apache.logging.log4j;
>>> 
>>> then when I run the app, the JVM will automatically add `log4j-api` to
>>> the boot layer.
>>> 
>>> It will also add `log4j-core`, since it provides a service that
>>> `log4j-api` uses.
>>> 
>>> However it will **not** load `jackson-datatype-yaml`, because it is an
>>> **optional** dependency of `log4j-core` and provides no services
>>> `log4j-core` is interested in. The user must go to the additional pain
>>> of specifying `--add-modules` or the application developer must add a
>>> bogus `requires` statement.
>>> 
>>> Therefore I would propose to:
>>> 
>>> * move the YAML configuration factory to a separate module and delete
>>> one of the JSON configuration factories (the one that uses Jackson).
>>> 
>>> What do you think?
>>> 
> 

Re: Optional dependencies and JPMS

[Ralph Goers]

I agree with this. IMO the only configuration syntaxes we should support are 
those we can implement with no dependencies. At the moment that is JSON and 
Properties (Ugh!). I would love to deprecate properties but I know that is a 
non-starter since we didn’t support them for years and were constantly asked 
for it.

Ralph

> On Nov 29, 2023, at 5:14 AM, Gary Gregory  wrote:
> 
> I think the overall goal should be to have no optional dependencies, no
> surprises. I personally hope to never force YAML on anyone.
> 
> Gary
> 
> On Wed, Nov 29, 2023, 6:51 AM Piotr P. Karwasz 
> wrote:
> 
>> Hi all,
>> 
>> I have been using a modularized sandbox project to test Log4j and
>> optional dependencies are a nightmare.
>> 
>> Small example: if I use Log4j API in my project and I add:
>> 
>> requires org.apache.logging.log4j;
>> 
>> then when I run the app, the JVM will automatically add `log4j-api` to
>> the boot layer.
>> 
>> It will also add `log4j-core`, since it provides a service that
>> `log4j-api` uses.
>> 
>> However it will **not** load `jackson-datatype-yaml`, because it is an
>> **optional** dependency of `log4j-core` and provides no services
>> `log4j-core` is interested in. The user must go to the additional pain
>> of specifying `--add-modules` or the application developer must add a
>> bogus `requires` statement.
>> 
>> Therefore I would propose to:
>> 
>> * move the YAML configuration factory to a separate module and delete
>> one of the JSON configuration factories (the one that uses Jackson).
>> 
>> What do you think?
>> 

Re: Optional dependencies and JPMS

[Gary Gregory]

I think the overall goal should be to have no optional dependencies, no
surprises. I personally hope to never force YAML on anyone.

Gary

On Wed, Nov 29, 2023, 6:51 AM Piotr P. Karwasz 
wrote:

> Hi all,
>
> I have been using a modularized sandbox project to test Log4j and
> optional dependencies are a nightmare.
>
> Small example: if I use Log4j API in my project and I add:
>
> requires org.apache.logging.log4j;
>
> then when I run the app, the JVM will automatically add `log4j-api` to
> the boot layer.
>
> It will also add `log4j-core`, since it provides a service that
> `log4j-api` uses.
>
> However it will **not** load `jackson-datatype-yaml`, because it is an
> **optional** dependency of `log4j-core` and provides no services
> `log4j-core` is interested in. The user must go to the additional pain
> of specifying `--add-modules` or the application developer must add a
> bogus `requires` statement.
>
> Therefore I would propose to:
>
>  * move the YAML configuration factory to a separate module and delete
> one of the JSON configuration factories (the one that uses Jackson).
>
> What do you think?
>

Optional dependencies and JPMS

[Piotr P. Karwasz]

Hi all,

I have been using a modularized sandbox project to test Log4j and
optional dependencies are a nightmare.

Small example: if I use Log4j API in my project and I add:

requires org.apache.logging.log4j;

then when I run the app, the JVM will automatically add `log4j-api` to
the boot layer.

It will also add `log4j-core`, since it provides a service that
`log4j-api` uses.

However it will **not** load `jackson-datatype-yaml`, because it is an
**optional** dependency of `log4j-core` and provides no services
`log4j-core` is interested in. The user must go to the additional pain
of specifying `--add-modules` or the application developer must add a
bogus `requires` statement.

Therefore I would propose to:

 * move the YAML configuration factory to a separate module and delete
one of the JSON configuration factories (the one that uses Jackson).

What do you think?