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
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 n
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
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 re
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
>
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
