Ralph, mind elaborating a bit more on what the exact problem is, please? `log4j.configuration` gets detected, log4j-1.2-api (provided by Log4j 2) kicks in, and tries to load the Log4j 1 configuration. This sounds okay to me. I guess it gets messed up when an application uses both Log4j 1 and 2, right?
On Wed, Dec 22, 2021 at 5:14 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > Volkan pointed out that the issue number in the subject was wrong. > > Ralph > > > On Dec 21, 2021, at 10:30 PM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > > This ticket complains because ConfigurationFactory looks to see if a > system property named log4j.configuration is set. > > If it is then it tries to initialize the configuration it points to as a > Log4j 1.x configuration using the PropertiesConfiguration I implemented. > > > > Unfortunately, this is the same property name that Log4j 1.x uses. I > probably thought it was a good thing at the time > > but now that I think about it I believe it was a mistake. > > > > The Log4j 1.x compatibility is still marked experimental. So I would > like to propose that the property be renamed to log4j1.configurationFile. > > It matches the format used for the Log4j 2 property but is clearly meant > to reference a Log4j 1.x configuration. This would require users > > who are using the compatibility (if there are any) to change the system > property name but it would allow log4j 1.x to continue to function > > if it is present in the app. > > > > I do have a concern. Is this going to somehow be renamed as > log4j2.log4j1.configurationFile by the properties system? That is ugly. > > > > Thoughts? > > > > Ralph > >
