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