Steve Cohen created LOG4J2-1713:
-----------------------------------
Summary: Allow for more general serialization of Log4j2
configurations
Key: LOG4J2-1713
URL: https://issues.apache.org/jira/browse/LOG4J2-1713
Project: Log4j 2
Issue Type: New Feature
Components: Configurators
Affects Versions: 2.7
Reporter: Steve Cohen
We want to implement the following system:
We would like to write an external program that reads several Log4j
Configuration Files, combines the configurations, and then outputs the combined
configuration to a new Log4j configuration file. This file can then simply be
dropped on a running log4j instance on a server, and cause an update of the
running configuration.
Existing APIs do not support this use case. There is nothing that supports the
serialization to XML of a loaded configuration. There is the new
ConfigurationBuilder.writeToXml() method in 2.7, but that's on
ConfigurationBuilder, not Configuration. Nor is it possible to take a
Configuration, and get a ConfigurationBuilder from it. Another way it could
work is having some sort of ConfigurationBuilder that accepted parameters of
type Logger, Appender, etc. These would enable Loggers and Appenders and other
Log4j2 objects to be copied from an existing configuration to a new one being
built. But this doesn't exist either. One would have to drill down into each
component, extract the necessary data, and add it to a builder.
In other words (H/T to Gary Gregory)
c1 = load config from XML file 1 (but do not apply the c1 configuration)
c2 = load config from XML file 2 (but do not apply the c2 configuration)
c3 = c1 + c2 (but do not apply the c3 configuration) write c3 to disk
In case you wonder, there is actually a use case behind this:
Imagine a Servlet web-app that, depending on request parameters, invokes one of
a number of possible EJBs (they could also be non-EJB POJOs, but for the
purposes of this discussion, we assume EJBs), in order to produce a response.
This is not a shopping cart but a back end system. We do NOT wish to deploy
these into a single EAR file but want separate deployment of each component,
and each component to have a separate logging configuration, deployable at the
same time as the component. Since Log4j allows only one configuration context
per class-loader, the ideal scheme would be there can only be one configuration
file. The only way to update it non-programatically is to drop a new
configuration in the correct location. In order to produce this, we would like
the separate logging configs deployed to some directory. A separate program
would read in all of these and add the loggers and appenders to a new master
configuration which would then be written out to disk and copied to the proper
location. The usual change mechanism would then load the new configuration.
The current configuration of the running system would always match what is in
this master configuration file, which is not the case with programmatic
configuration.
Without something like this, how is it possible to run multiple EJBs out of a
web-app that are separately deployable and have separately manageable logging
configurations?
One could manually of course parse the individual files on the XML level (or
JSON, YAML, whatever), combine them, and serialize the output. But since log4j
knows its own object model better than any xml parser, it makes sense to have
this capability within log4j.
And yes, I've thought of the fact that property-name, logger-name,
appender-name collisions are possible and could cause trouble. I would be
prepared to live with real restrictions that prevent this. I don't think there
is any need to support concatenation of random config files that do not prevent
such collisions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
