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 <mailto:org.jboss.as.jmx@12.0.3.Final>//org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1518) at org.jboss.as.jmx@12.0.3.Final <mailto:org.jboss.as.jmx@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 <ralph.go...@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 <arnie.mor...@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-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org >
