Re: Log to configure Log4j for multi-module EAR project

Arnold Morein <[email protected]>
Newsgroups gmane.comp.jakarta.log4j.user
Message-ID <[email protected]>
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 <[email protected]> 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 <[email protected]> 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 [email protected] <mailto:[email protected]>//org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.registerMBean(PluggableMBeanServerImpl.java:1518)
>> at [email protected] <mailto:[email protected]>//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 <[email protected]> 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 <[email protected]> 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: [email protected]
>>> For additional commands, e-mail: [email protected]
>>> 
>> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.