[jira] [Commented] (LOG4J2-1713) Allow for more general serialization of Log4j2 configurations
[ https://issues.apache.org/jira/browse/LOG4J2-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15812998#comment-15812998 ] Kurt Seidel commented on LOG4J2-1713: - Thanks for the reply. I think that answers my question. I am using the default ClassLoaderContextSelector, and as you point out, and as I have found, this only allows a single LoggerContext per ClassLoader. Most of our logging is done within the context of webapps, where each webapp has it's own log configuration, and the log4j2 jar files are bundled into the webapp's WEB-INF/lib. Creating a customized ContextSelector to solve my problem sounds like it would interfere with the ClassLoaderContextSelector required for proper isolated webapp logging, since this custom ContextSelector class is specified at the system level. I will likely go with using the Composite Configuration to deal with the common jars. > 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)
[jira] [Commented] (LOG4J2-1713) Allow for more general serialization of Log4j2 configurations
[ https://issues.apache.org/jira/browse/LOG4J2-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15802528#comment-15802528 ] Kurt Seidel commented on LOG4J2-1713: - Yes I noticed that when I researched that error, but in all cases I saw it had to do with creating a some super jar with included all dependencies (shade plugin?). I'm not doing anything like that. I'm just including the standard log4j2 jars (log4j-api-2.7.jar, log4j-core-2.7.jar, log4j-web-2.7.jar) in my WEB-INF/lib, so I don't see how could not be finding the DAT file. I also have log4j-api-2.7.jar and log4j-core-2.7.jar in tomcat's lib directory (for use by my test Jars installed there). I look forward to your response once you have time to read my entire post. 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: log4j-dev-unsubscr...@logging.apache.org For
[jira] [Commented] (LOG4J2-1713) Allow for more general serialization of Log4j2 configurations
[
https://issues.apache.org/jira/browse/LOG4J2-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15802416#comment-15802416
]
Kurt Seidel commented on LOG4J2-1713:
-
Gary - thanks for the tip. I was hopeful that this would work, but it does not
appear to. It appears that you are still limited to one LoggerContext per
classloader.
I created a simple webapp project, and 2 simple Java projects, each of which
just creates a jar file (jarA and jarB) with a couple simple classes that just
log a message. I would like to have separate log4j2.xml config files for each
of these Jar projects. jarA.jar and jarB.jar are both installed in tomcat's lib
directory. My webapp's servlet just creates creates an object from each of
these jars, and calls a method to induce a log message to be written by these
objects.
The logging for the classes in the webapp and jars are configured as follows:
public class LogTest extends HttpServlet {
private static final LoggerContext logctx =
Configurator.initialize("/tmp/junk/LogTest/webapp/log4j2.xml", "LOGTEST");
private static Logger log = logctx.getLogger(LogTest.class.getName());
public class JarAMainBean {
private static final LoggerContext logctx =
Configurator.initialize("/tmp/junk/LogTest/jarA/log4j2.xml", "JarA");
private static Logger log =
logctx.getLogger(JarAMainBean.class.getName());
public class JarBMainBean {
private static final LoggerContext logctx =
Configurator.initialize("/tmp/junk/LogTest/jarB/log4j2.xml", "JarB");
private static Logger log =
logctx.getLogger(JarBMainBean.class.getName());
There are 2 issues:
1) When I have the log4j2 jar files bundled in my webapp's web-inf/lib, I get
the following log4j2 errors when creating either one of the objects above (I
believe because the LoggerContext for the webapp classloader has already been
configured):
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position
16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at
position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at
position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at
position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position
54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position
56 in conversion pattern.
ERROR StatusLogger No log4j2 configuration file found. Using default
configuration: logging only errors to the console.
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position
16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at
position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at
position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at
position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position
54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position
56 in conversion pattern.
2) When I remove the log4j2 jars from my webapp's web-inf/lib, the logger for
the servlet gets created fine (as in the case above), and this time the logger
for the first Jar gets created fine, when the object from that Jar is created.
HOWEVER, when the servlet creates the object from the 2nd Jar, I get this
log4j2 ERROR:
WARN locateContext called with URI /tmp/junk/LogTest/jarA/log4j2.xml. Existing
LoggerContext has URI /tmp/junk/LogTest/jarB/log4j2.xml
So, even though the classes in each jar are creating a LoggerContext with their
own unique name, log4j2 is not letting you create the LoggerContext for the 2nd
jar, seemingly because a LoggerContext has already been configured for that
(system/common) classloader
For reference sake, the code in my servlet's doGet() method is:
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
