[
https://issues.apache.org/jira/browse/LOG4J2-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Cohen updated LOG4J2-1713:
--------------------------------
Comment: was deleted
(was: Hmm. I didn't know about {code}@PreDestroy{code}. It sounds like what I
am looking for. Thanks!)
> 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: [email protected]
For additional commands, e-mail: [email protected]
