This one; log4j2.component.properties. That's good indeed, as of now, our tooling is not something I can easily update to generate a new file that then gets propagated to the right place. But it is "simple" to add another entry to an existing file. Not something Log4j needs to worry about of course.
Gary On Mon, Dec 20, 2021 at 2:24 PM Matt Sicker <[email protected]> wrote: > > Without additional refactoring, the only way this would work is if the > logging config is the only config in the application. System > properties are global to the JVM. There's already a properties file > you can include that gets loaded as a log4j2 system properties file, > by the way. > > On Mon, Dec 20, 2021 at 1:19 PM Gary Gregory <[email protected]> wrote: > > > > Hello, > > > > I'd like to propose that we add an element called SystemProperty to > > our configuration. This would look like our current Property element > > but would set a system property instead of a configuration property. > > > > My use case is, at work, our tooling generates one XML configuration > > file for a user's project and additional XML files for each DTAP > > environment. The main Log4j configuration file uses XInclude to bring > > in the appropriate DTAP file. Depending on the configuration of the > > user's project, and in light of Log4j's use of system properties, > > specifically, our new enableJndi* system properties, it would be nice > > to be able to say in DTAP XML files something like <SystemProperty > > key="enableJndiJms>true</SystemProperty> or whatever Property > > supports. > > > > Thoughts? > > > > Gary
