[
https://issues.apache.org/jira/browse/LOG4J2-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15674729#comment-15674729
]
Steve Cohen edited comment on LOG4J2-1713 at 11/17/16 8:34 PM:
---------------------------------------------------------------
??Would that help???
Hmm. Maybe it would.
I already started down a similar path, except I was using
{code}
private static final String LOGGER_CONFIG =
"/usr/local/myejb/config/log4j2.xml";
static {
Configurator.initialize(null, LOGGER_CONFIG);
}
{code} with null for the name. I called this initialize statically in the EJB
class. I gave up on this approach, when I noticed that after several
deployments/undeployments of my ejb jar, these contexts were still persisting
in the server, even though they weren't doing anything (there's no shutdown
hook as there is with the web-app). If I knew how to create such a shutdown
hook when the EJB was undeployed, since with your approach, I would know its
name, this might work for me.
was (Author: sc1478):
??Would that help???
Hmm. Maybe it would.
I already started down a similar path, except I was using
{code}
private static final String LOGGER_CONFIG =
"/usr/local/myejb/config/log4j2.xml";
static {
Configurator.initialize(null, LOGGER_CONFIG);
}
{code} with null for the name. I called this initialize statically in the EJB
class. I gave up on this approach, when I noticed that after several
deployments/undeployments of my ejb jar, these contexts were still persisting
in the server, even though they weren't doing anything (there's no shutdown
hook as there is with the web-app). If I knew how to create such a shutdown
hook when the EJB was undeployed, even if I knew its name, this might work for
me.
> 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]
