You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Arnold Morein <ar...@mac.com.INVALID> on 2021/01/07 23:17:23 UTC
Log to configure Log4j for multi-module EAR project
I’ve looked high and low and there is nothing but vague references and comments, most of them stale.
I have an EAR with two EJB modules and a WAR module.
The log4j and slf4j jars are in the EAR’s /lib folder. Each module has a log4j2.xml/.dtd pair in the META-INF folder, except the WAR where it is in WEB-INF/classes. The WAR project also has log4j-web.jar in its /lib folder.
Deploying on Wildfly 21. The loggers defined in the WAR’s log4j2.xml file are created because the files are created. The ones from the EJB modules are not.
I even went to the point of creating a @Startup/@Singleton class in each of the EJB modules that does this:
ConfigurationBuilder<BuiltConfiguration> configBuilder = ConfigurationBuilderFactory.newConfigurationBuilder();
InputStream inputStream = Thread.currentThread().getContextClassLoader().getResourceAsStream("META-INF/log4j2.xml");
ConfigurationSource configurationSource = new ConfigurationSource(inputStream);
configBuilder.setConfigurationSource(configurationSource);
loggerContext = Configurator.initialize(configBuilder.build());
loggerContext.initialize();
loggerContext.start();
I can step through the code and it all works. The XML file is read just fine (can send the stream to a string and it is correct).
No exception is thrown (from either of the other two modules); but the files are not being opened and nothing written.
Each of the 3 xml files have the same at the top, but only the WAR instance is recognized:
<properties>
<!-- when using file logger -->
<property name="maxDays">90</property>
<property name="maxFileSize">20 MB</property>
<property name="logBaseDir">/logs/app_name</property>
<property name="patternStr">%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %l - %msg%n</property>
</properties>
<Appenders>
<Console
name="STDOUT"
target="SYSTEM_OUT"
>
<PatternLayout pattern="${patternStr}" />
</Console>
<RollingFile
name=“APP_NAME_DB"
fileName="${logBaseDir}/${hostName}_app_name_db.log"
filePattern="${logBaseDir}/rotated/${hostName}_app_name_db.%d{yyyy-MM-dd}-%i.log.gz"
>
<PatternLayout pattern="${patternStr}" />
<Policies>
<OnStartupTriggeringPolicy />
<SizeBasedTriggeringPolicy size="${maxFileSize}" />
<TimeBasedTriggeringPolicy />
</Policies>
<DefaultRolloverStrategy max="${maxDays}" />
</RollingFile>
Re: Log to configure Log4j for multi-module EAR project
Posted by Matt Sicker <bo...@gmail.com>.
The general idea would be to tie the lifecycle of a log4j config to
its underlying logical container whether that be the entire JVM (the
more common use case), a war, an ejb, a rar, whatever the unit of
containerization is inside the JVM. If the EE server itself is using
Log4j for its logging, then you'd want that config separated from the
individual EE containers. There's an example of this sort of pattern
in the OSGi support code, but that's structured around individual jar
modules rather than larger container type things.
On Fri, 8 Jan 2021 at 12:36, Arnold Morein <ar...@mac.com.invalid> wrote:
>
> A tall task for me, but I will think about it.
>
> Can you give any information as to if log4j is supposed to auto-start w/i an EJB deployment like it does a WAR? And if so, would that be the responsibility of the container (WIldfly in this case, or Tomcat), or is some class from -core suppose to notice the deployment?
>
> > On Jan 8, 2021, at 12:10 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> >
> > No, there is probably not a guide. I personally haven’t done anything with EJBs or JBoss in about 10 years now. But yes, I could see how having multiple MBeans could be a problem. I’d bet that since no one has looked at this that none of the other committers do either. If you would care to spend some time looking into this your help would be most welcome.
> >
> > Ralph
> >
> >> On Jan 8, 2021, at 9:42 AM, Arnold Morein <ar...@mac.com.INVALID> wrote:
> >>
> >> Unusual? I don’t see why not. /logs is a mount point for a discreet volume that is separate from /app and the rest of the RHEL standard mount points. That way, each can be sized appropriately and neither can directly impact the other. If /logs were to fill up and server would hang but a quick resize and it recovers nicely.
> >>
> >> But that’s a different topic. :)
> >>
> >> I turned on the debug but that had no effect. Why? Because I had missed TWO exceptions in the log (one for each of the two custom logger start up beans):
> >>
> >> ERROR Could not register mbeans javax.management.InstanceAlreadyExistsException: org.apache.logging.log4j2:type=70983983
> >> at java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
> >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855)
> >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955)
> >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
> >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
> >> at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> >> at org.jboss.as.jmx@12.0.3.Final <ma...@12.0.3.Final>//org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1518)
> >> at org.jboss.as.jmx@12.0.3.Final <ma...@12.0.3.Final>//org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:874)
> >> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.register(Server.java:393)
> >> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:168)
> >> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:141)
> >> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:629)
> >> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:295)
> >> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:207)
> >> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:221)
> >> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:197)
> >> at deployment.app-name-1.0.0.ear.app-name-db.jar//a/b.c.appname.db.util.StartLogging.postConstruct(StartLogging.java:41)
> >>
> >> I’ve seen similar messages and apparently this is an old issue that has still to be resolved. Re: https://issues.apache.org/jira/browse/LOG4J2-1094 <https://issues.apache.org/jira/browse/LOG4J2-1094>
> >>
> >> I do not see a clear guide on the Log4j or Wildly web sites about how to configure a logging context inside an EJB… whether deployed in an EAR or standalone.
> >>
> >> Is there one?
> >>
> >>
> >>> On Jan 7, 2021, at 9:29 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> >>>
> >>> You really have a directory at the root of your file system named “logs”? That is a bit unusual.
> >>>
> >>> I would suggest setting status=debug on the configuration element so you can see what the rolling file appender is resolving the file name to.
> >>>
> >>> Ralph
> >>>
> >>>> On Jan 7, 2021, at 4:17 PM, Arnold Morein <ar...@mac.com.INVALID> wrote:
> >>>>
> >>>> I’ve looked high and low and there is nothing but vague references and comments, most of them stale.
> >>>>
> >>>> I have an EAR with two EJB modules and a WAR module.
> >>>>
> >>>> The log4j and slf4j jars are in the EAR’s /lib folder. Each module has a log4j2.xml/.dtd pair in the META-INF folder, except the WAR where it is in WEB-INF/classes. The WAR project also has log4j-web.jar in its /lib folder.
> >>>>
> >>>> Deploying on Wildfly 21. The loggers defined in the WAR’s log4j2.xml file are created because the files are created. The ones from the EJB modules are not.
> >>>>
> >>>> I even went to the point of creating a @Startup/@Singleton class in each of the EJB modules that does this:
> >>>>
> >>>>
> >>>> ConfigurationBuilder<BuiltConfiguration> configBuilder = ConfigurationBuilderFactory.newConfigurationBuilder();
> >>>> InputStream inputStream = Thread.currentThread().getContextClassLoader().getResourceAsStream("META-INF/log4j2.xml");
> >>>> ConfigurationSource configurationSource = new ConfigurationSource(inputStream);
> >>>> configBuilder.setConfigurationSource(configurationSource);
> >>>> loggerContext = Configurator.initialize(configBuilder.build());
> >>>> loggerContext.initialize();
> >>>> loggerContext.start();
> >>>>
> >>>> I can step through the code and it all works. The XML file is read just fine (can send the stream to a string and it is correct).
> >>>>
> >>>> No exception is thrown (from either of the other two modules); but the files are not being opened and nothing written.
> >>>>
> >>>> Each of the 3 xml files have the same at the top, but only the WAR instance is recognized:
> >>>>
> >>>> <properties>
> >>>> <!-- when using file logger -->
> >>>> <property name="maxDays">90</property>
> >>>> <property name="maxFileSize">20 MB</property>
> >>>> <property name="logBaseDir">/logs/app_name</property>
> >>>> <property name="patternStr">%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %l - %msg%n</property>
> >>>> </properties>
> >>>>
> >>>> <Appenders>
> >>>> <Console
> >>>> name="STDOUT"
> >>>> target="SYSTEM_OUT"
> >>>>>
> >>>> <PatternLayout pattern="${patternStr}" />
> >>>> </Console>
> >>>> <RollingFile
> >>>> name=“APP_NAME_DB"
> >>>> fileName="${logBaseDir}/${hostName}_app_name_db.log"
> >>>> filePattern="${logBaseDir}/rotated/${hostName}_app_name_db.%d{yyyy-MM-dd}-%i.log.gz"
> >>>>>
> >>>> <PatternLayout pattern="${patternStr}" />
> >>>> <Policies>
> >>>> <OnStartupTriggeringPolicy />
> >>>> <SizeBasedTriggeringPolicy size="${maxFileSize}" />
> >>>> <TimeBasedTriggeringPolicy />
> >>>> </Policies>
> >>>> <DefaultRolloverStrategy max="${maxDays}" />
> >>>> </RollingFile>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log to configure Log4j for multi-module EAR project
Posted by Arnold Morein <ar...@mac.com.INVALID>.
A tall task for me, but I will think about it.
Can you give any information as to if log4j is supposed to auto-start w/i an EJB deployment like it does a WAR? And if so, would that be the responsibility of the container (WIldfly in this case, or Tomcat), or is some class from -core suppose to notice the deployment?
> On Jan 8, 2021, at 12:10 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> No, there is probably not a guide. I personally haven’t done anything with EJBs or JBoss in about 10 years now. But yes, I could see how having multiple MBeans could be a problem. I’d bet that since no one has looked at this that none of the other committers do either. If you would care to spend some time looking into this your help would be most welcome.
>
> Ralph
>
>> On Jan 8, 2021, at 9:42 AM, Arnold Morein <ar...@mac.com.INVALID> wrote:
>>
>> Unusual? I don’t see why not. /logs is a mount point for a discreet volume that is separate from /app and the rest of the RHEL standard mount points. That way, each can be sized appropriately and neither can directly impact the other. If /logs were to fill up and server would hang but a quick resize and it recovers nicely.
>>
>> But that’s a different topic. :)
>>
>> I turned on the debug but that had no effect. Why? Because I had missed TWO exceptions in the log (one for each of the two custom logger start up beans):
>>
>> ERROR Could not register mbeans javax.management.InstanceAlreadyExistsException: org.apache.logging.log4j2:type=70983983
>> at java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
>> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855)
>> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955)
>> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
>> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
>> at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
>> at org.jboss.as.jmx@12.0.3.Final <ma...@12.0.3.Final>//org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1518)
>> at org.jboss.as.jmx@12.0.3.Final <ma...@12.0.3.Final>//org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:874)
>> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.register(Server.java:393)
>> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:168)
>> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:141)
>> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:629)
>> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:295)
>> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:207)
>> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:221)
>> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:197)
>> at deployment.app-name-1.0.0.ear.app-name-db.jar//a/b.c.appname.db.util.StartLogging.postConstruct(StartLogging.java:41)
>>
>> I’ve seen similar messages and apparently this is an old issue that has still to be resolved. Re: https://issues.apache.org/jira/browse/LOG4J2-1094 <https://issues.apache.org/jira/browse/LOG4J2-1094>
>>
>> I do not see a clear guide on the Log4j or Wildly web sites about how to configure a logging context inside an EJB… whether deployed in an EAR or standalone.
>>
>> Is there one?
>>
>>
>>> On Jan 7, 2021, at 9:29 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>> You really have a directory at the root of your file system named “logs”? That is a bit unusual.
>>>
>>> I would suggest setting status=debug on the configuration element so you can see what the rolling file appender is resolving the file name to.
>>>
>>> Ralph
>>>
>>>> On Jan 7, 2021, at 4:17 PM, Arnold Morein <ar...@mac.com.INVALID> wrote:
>>>>
>>>> I’ve looked high and low and there is nothing but vague references and comments, most of them stale.
>>>>
>>>> I have an EAR with two EJB modules and a WAR module.
>>>>
>>>> The log4j and slf4j jars are in the EAR’s /lib folder. Each module has a log4j2.xml/.dtd pair in the META-INF folder, except the WAR where it is in WEB-INF/classes. The WAR project also has log4j-web.jar in its /lib folder.
>>>>
>>>> Deploying on Wildfly 21. The loggers defined in the WAR’s log4j2.xml file are created because the files are created. The ones from the EJB modules are not.
>>>>
>>>> I even went to the point of creating a @Startup/@Singleton class in each of the EJB modules that does this:
>>>>
>>>>
>>>> ConfigurationBuilder<BuiltConfiguration> configBuilder = ConfigurationBuilderFactory.newConfigurationBuilder();
>>>> InputStream inputStream = Thread.currentThread().getContextClassLoader().getResourceAsStream("META-INF/log4j2.xml");
>>>> ConfigurationSource configurationSource = new ConfigurationSource(inputStream);
>>>> configBuilder.setConfigurationSource(configurationSource);
>>>> loggerContext = Configurator.initialize(configBuilder.build());
>>>> loggerContext.initialize();
>>>> loggerContext.start();
>>>>
>>>> I can step through the code and it all works. The XML file is read just fine (can send the stream to a string and it is correct).
>>>>
>>>> No exception is thrown (from either of the other two modules); but the files are not being opened and nothing written.
>>>>
>>>> Each of the 3 xml files have the same at the top, but only the WAR instance is recognized:
>>>>
>>>> <properties>
>>>> <!-- when using file logger -->
>>>> <property name="maxDays">90</property>
>>>> <property name="maxFileSize">20 MB</property>
>>>> <property name="logBaseDir">/logs/app_name</property>
>>>> <property name="patternStr">%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %l - %msg%n</property>
>>>> </properties>
>>>>
>>>> <Appenders>
>>>> <Console
>>>> name="STDOUT"
>>>> target="SYSTEM_OUT"
>>>>>
>>>> <PatternLayout pattern="${patternStr}" />
>>>> </Console>
>>>> <RollingFile
>>>> name=“APP_NAME_DB"
>>>> fileName="${logBaseDir}/${hostName}_app_name_db.log"
>>>> filePattern="${logBaseDir}/rotated/${hostName}_app_name_db.%d{yyyy-MM-dd}-%i.log.gz"
>>>>>
>>>> <PatternLayout pattern="${patternStr}" />
>>>> <Policies>
>>>> <OnStartupTriggeringPolicy />
>>>> <SizeBasedTriggeringPolicy size="${maxFileSize}" />
>>>> <TimeBasedTriggeringPolicy />
>>>> </Policies>
>>>> <DefaultRolloverStrategy max="${maxDays}" />
>>>> </RollingFile>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log to configure Log4j for multi-module EAR project
Posted by Ralph Goers <ra...@dslextreme.com>.
No, there is probably not a guide. I personally haven’t done anything with EJBs or JBoss in about 10 years now. But yes, I could see how having multiple MBeans could be a problem. I’d bet that since no one has looked at this that none of the other committers do either. If you would care to spend some time looking into this your help would be most welcome.
Ralph
> On Jan 8, 2021, at 9:42 AM, Arnold Morein <ar...@mac.com.INVALID> wrote:
>
> Unusual? I don’t see why not. /logs is a mount point for a discreet volume that is separate from /app and the rest of the RHEL standard mount points. That way, each can be sized appropriately and neither can directly impact the other. If /logs were to fill up and server would hang but a quick resize and it recovers nicely.
>
> But that’s a different topic. :)
>
> I turned on the debug but that had no effect. Why? Because I had missed TWO exceptions in the log (one for each of the two custom logger start up beans):
>
> ERROR Could not register mbeans javax.management.InstanceAlreadyExistsException: org.apache.logging.log4j2:type=70983983
> at java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855)
> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955)
> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
> at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at org.jboss.as.jmx@12.0.3.Final <ma...@12.0.3.Final>//org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1518)
> at org.jboss.as.jmx@12.0.3.Final <ma...@12.0.3.Final>//org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:874)
> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.register(Server.java:393)
> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:168)
> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:141)
> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:629)
> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:295)
> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:207)
> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:221)
> at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:197)
> at deployment.app-name-1.0.0.ear.app-name-db.jar//a/b.c.appname.db.util.StartLogging.postConstruct(StartLogging.java:41)
>
> I’ve seen similar messages and apparently this is an old issue that has still to be resolved. Re: https://issues.apache.org/jira/browse/LOG4J2-1094 <https://issues.apache.org/jira/browse/LOG4J2-1094>
>
> I do not see a clear guide on the Log4j or Wildly web sites about how to configure a logging context inside an EJB… whether deployed in an EAR or standalone.
>
> Is there one?
>
>
>> On Jan 7, 2021, at 9:29 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>> You really have a directory at the root of your file system named “logs”? That is a bit unusual.
>>
>> I would suggest setting status=debug on the configuration element so you can see what the rolling file appender is resolving the file name to.
>>
>> Ralph
>>
>>> On Jan 7, 2021, at 4:17 PM, Arnold Morein <ar...@mac.com.INVALID> wrote:
>>>
>>> I’ve looked high and low and there is nothing but vague references and comments, most of them stale.
>>>
>>> I have an EAR with two EJB modules and a WAR module.
>>>
>>> The log4j and slf4j jars are in the EAR’s /lib folder. Each module has a log4j2.xml/.dtd pair in the META-INF folder, except the WAR where it is in WEB-INF/classes. The WAR project also has log4j-web.jar in its /lib folder.
>>>
>>> Deploying on Wildfly 21. The loggers defined in the WAR’s log4j2.xml file are created because the files are created. The ones from the EJB modules are not.
>>>
>>> I even went to the point of creating a @Startup/@Singleton class in each of the EJB modules that does this:
>>>
>>>
>>> ConfigurationBuilder<BuiltConfiguration> configBuilder = ConfigurationBuilderFactory.newConfigurationBuilder();
>>> InputStream inputStream = Thread.currentThread().getContextClassLoader().getResourceAsStream("META-INF/log4j2.xml");
>>> ConfigurationSource configurationSource = new ConfigurationSource(inputStream);
>>> configBuilder.setConfigurationSource(configurationSource);
>>> loggerContext = Configurator.initialize(configBuilder.build());
>>> loggerContext.initialize();
>>> loggerContext.start();
>>>
>>> I can step through the code and it all works. The XML file is read just fine (can send the stream to a string and it is correct).
>>>
>>> No exception is thrown (from either of the other two modules); but the files are not being opened and nothing written.
>>>
>>> Each of the 3 xml files have the same at the top, but only the WAR instance is recognized:
>>>
>>> <properties>
>>> <!-- when using file logger -->
>>> <property name="maxDays">90</property>
>>> <property name="maxFileSize">20 MB</property>
>>> <property name="logBaseDir">/logs/app_name</property>
>>> <property name="patternStr">%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %l - %msg%n</property>
>>> </properties>
>>>
>>> <Appenders>
>>> <Console
>>> name="STDOUT"
>>> target="SYSTEM_OUT"
>>>>
>>> <PatternLayout pattern="${patternStr}" />
>>> </Console>
>>> <RollingFile
>>> name=“APP_NAME_DB"
>>> fileName="${logBaseDir}/${hostName}_app_name_db.log"
>>> filePattern="${logBaseDir}/rotated/${hostName}_app_name_db.%d{yyyy-MM-dd}-%i.log.gz"
>>>>
>>> <PatternLayout pattern="${patternStr}" />
>>> <Policies>
>>> <OnStartupTriggeringPolicy />
>>> <SizeBasedTriggeringPolicy size="${maxFileSize}" />
>>> <TimeBasedTriggeringPolicy />
>>> </Policies>
>>> <DefaultRolloverStrategy max="${maxDays}" />
>>> </RollingFile>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Log to configure Log4j for multi-module EAR project
Posted by Arnold Morein <ar...@mac.com.INVALID>.
Unusual? I don’t see why not. /logs is a mount point for a discreet volume that is separate from /app and the rest of the RHEL standard mount points. That way, each can be sized appropriately and neither can directly impact the other. If /logs were to fill up and server would hang but a quick resize and it recovers nicely.
But that’s a different topic. :)
I turned on the debug but that had no effect. Why? Because I had missed TWO exceptions in the log (one for each of the two custom logger start up beans):
ERROR Could not register mbeans javax.management.InstanceAlreadyExistsException: org.apache.logging.log4j2:type=70983983
at java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:436)
at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855)
at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955)
at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at org.jboss.as.jmx@12.0.3.Final <ma...@12.0.3.Final>//org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1518)
at org.jboss.as.jmx@12.0.3.Final <ma...@12.0.3.Final>//org.jboss.as.jmx.PluggableMBeanServerImpl.registerMBean(PluggableMBeanServerImpl.java:874)
at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.register(Server.java:393)
at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:168)
at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:141)
at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:629)
at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:295)
at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:207)
at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:221)
at deployment.app-name-1.0.0.ear//org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:197)
at deployment.app-name-1.0.0.ear.app-name-db.jar//a/b.c.appname.db.util.StartLogging.postConstruct(StartLogging.java:41)
I’ve seen similar messages and apparently this is an old issue that has still to be resolved. Re: https://issues.apache.org/jira/browse/LOG4J2-1094 <https://issues.apache.org/jira/browse/LOG4J2-1094>
I do not see a clear guide on the Log4j or Wildly web sites about how to configure a logging context inside an EJB… whether deployed in an EAR or standalone.
Is there one?
> On Jan 7, 2021, at 9:29 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> You really have a directory at the root of your file system named “logs”? That is a bit unusual.
>
> I would suggest setting status=debug on the configuration element so you can see what the rolling file appender is resolving the file name to.
>
> Ralph
>
>> On Jan 7, 2021, at 4:17 PM, Arnold Morein <ar...@mac.com.INVALID> wrote:
>>
>> I’ve looked high and low and there is nothing but vague references and comments, most of them stale.
>>
>> I have an EAR with two EJB modules and a WAR module.
>>
>> The log4j and slf4j jars are in the EAR’s /lib folder. Each module has a log4j2.xml/.dtd pair in the META-INF folder, except the WAR where it is in WEB-INF/classes. The WAR project also has log4j-web.jar in its /lib folder.
>>
>> Deploying on Wildfly 21. The loggers defined in the WAR’s log4j2.xml file are created because the files are created. The ones from the EJB modules are not.
>>
>> I even went to the point of creating a @Startup/@Singleton class in each of the EJB modules that does this:
>>
>>
>> ConfigurationBuilder<BuiltConfiguration> configBuilder = ConfigurationBuilderFactory.newConfigurationBuilder();
>> InputStream inputStream = Thread.currentThread().getContextClassLoader().getResourceAsStream("META-INF/log4j2.xml");
>> ConfigurationSource configurationSource = new ConfigurationSource(inputStream);
>> configBuilder.setConfigurationSource(configurationSource);
>> loggerContext = Configurator.initialize(configBuilder.build());
>> loggerContext.initialize();
>> loggerContext.start();
>>
>> I can step through the code and it all works. The XML file is read just fine (can send the stream to a string and it is correct).
>>
>> No exception is thrown (from either of the other two modules); but the files are not being opened and nothing written.
>>
>> Each of the 3 xml files have the same at the top, but only the WAR instance is recognized:
>>
>> <properties>
>> <!-- when using file logger -->
>> <property name="maxDays">90</property>
>> <property name="maxFileSize">20 MB</property>
>> <property name="logBaseDir">/logs/app_name</property>
>> <property name="patternStr">%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %l - %msg%n</property>
>> </properties>
>>
>> <Appenders>
>> <Console
>> name="STDOUT"
>> target="SYSTEM_OUT"
>>>
>> <PatternLayout pattern="${patternStr}" />
>> </Console>
>> <RollingFile
>> name=“APP_NAME_DB"
>> fileName="${logBaseDir}/${hostName}_app_name_db.log"
>> filePattern="${logBaseDir}/rotated/${hostName}_app_name_db.%d{yyyy-MM-dd}-%i.log.gz"
>>>
>> <PatternLayout pattern="${patternStr}" />
>> <Policies>
>> <OnStartupTriggeringPolicy />
>> <SizeBasedTriggeringPolicy size="${maxFileSize}" />
>> <TimeBasedTriggeringPolicy />
>> </Policies>
>> <DefaultRolloverStrategy max="${maxDays}" />
>> </RollingFile>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
Re: Log to configure Log4j for multi-module EAR project
Posted by Ralph Goers <ra...@dslextreme.com>.
You really have a directory at the root of your file system named “logs”? That is a bit unusual.
I would suggest setting status=debug on the configuration element so you can see what the rolling file appender is resolving the file name to.
Ralph
> On Jan 7, 2021, at 4:17 PM, Arnold Morein <ar...@mac.com.INVALID> wrote:
>
> I’ve looked high and low and there is nothing but vague references and comments, most of them stale.
>
> I have an EAR with two EJB modules and a WAR module.
>
> The log4j and slf4j jars are in the EAR’s /lib folder. Each module has a log4j2.xml/.dtd pair in the META-INF folder, except the WAR where it is in WEB-INF/classes. The WAR project also has log4j-web.jar in its /lib folder.
>
> Deploying on Wildfly 21. The loggers defined in the WAR’s log4j2.xml file are created because the files are created. The ones from the EJB modules are not.
>
> I even went to the point of creating a @Startup/@Singleton class in each of the EJB modules that does this:
>
>
> ConfigurationBuilder<BuiltConfiguration> configBuilder = ConfigurationBuilderFactory.newConfigurationBuilder();
> InputStream inputStream = Thread.currentThread().getContextClassLoader().getResourceAsStream("META-INF/log4j2.xml");
> ConfigurationSource configurationSource = new ConfigurationSource(inputStream);
> configBuilder.setConfigurationSource(configurationSource);
> loggerContext = Configurator.initialize(configBuilder.build());
> loggerContext.initialize();
> loggerContext.start();
>
> I can step through the code and it all works. The XML file is read just fine (can send the stream to a string and it is correct).
>
> No exception is thrown (from either of the other two modules); but the files are not being opened and nothing written.
>
> Each of the 3 xml files have the same at the top, but only the WAR instance is recognized:
>
> <properties>
> <!-- when using file logger -->
> <property name="maxDays">90</property>
> <property name="maxFileSize">20 MB</property>
> <property name="logBaseDir">/logs/app_name</property>
> <property name="patternStr">%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %l - %msg%n</property>
> </properties>
>
> <Appenders>
> <Console
> name="STDOUT"
> target="SYSTEM_OUT"
>>
> <PatternLayout pattern="${patternStr}" />
> </Console>
> <RollingFile
> name=“APP_NAME_DB"
> fileName="${logBaseDir}/${hostName}_app_name_db.log"
> filePattern="${logBaseDir}/rotated/${hostName}_app_name_db.%d{yyyy-MM-dd}-%i.log.gz"
>>
> <PatternLayout pattern="${patternStr}" />
> <Policies>
> <OnStartupTriggeringPolicy />
> <SizeBasedTriggeringPolicy size="${maxFileSize}" />
> <TimeBasedTriggeringPolicy />
> </Policies>
> <DefaultRolloverStrategy max="${maxDays}" />
> </RollingFile>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org