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 <ralph.go...@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 <arnie.mor...@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 >> <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 >>> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
