logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen (JIRA)" <j...@apache.org>
Subject [jira] [Created] (LOG4J2-1713) Allow for more general serialization of Log4j2 configurations
Date Thu, 17 Nov 2016 19:23:58 GMT
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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message