log4j2 logging of code in EJB jar on JBoss EAP 7

Question

I am doing the following: porting several legacy applications from WebLogic to JBoss EAP 7. Some of the components being ported are EJBs. Others are servlet apps that invoke these EJBs. These EJBs are deployed in ejb-jars. I know that I could wrap this whole thing into a big EAR file but we don't want to do that. The servlets and the EJB jars need to be separately deployable components.

Then there is the logging setup. We are using log4j2 and we want to keep independent of the JBoss logging setup. I have created a JBoss module that contains all the log4j2 jars with the proper dependencies, and logging works. The servlet runs and logs, invokes the EJBs and they work.

The only problem is how to configure the EJB's logging. In a Web App like the servlet, it's easy, just specify the log4j logging configuration file in web.xml. What's the analog for an ejb jar? I couldn't think of a way.

I tried the following: Add a logger/appender to the configuration of the servlet app for the EJB package and specify a new file. It doesn't work. The new logfile does get created but nothing gets written to the logfile. There should be output, but there isn't, so evidently when the EJB runs, its LogManager is not using the configuration specified in the servlet.

What is the right way for specifying a log4j2 configuration in an EJB deployed in an EJB jar on JBoss EAP7?

Answer 1

I had previously posted in this space a solution involving use of the @postConstruct and @preDestroy methods to initialize and shut down LoggerContext objects.

This plan fell apart when I tried to extend it to stateless session beans. It worked okay for Stateful Beans. Or so I thought. Eventually I found an Oracle document on EJB Restrictions which exposed the weaknesses in what I was doing. My "solution" included a non-final static LoggerContext member of the EJB class. I found a way to make it final, which did allow the stateless case to work. But I was increasingly dissatisfied with my approach. Even in the stateful case, I found issues that might bite me later in a clustered environment.

What I now come to believe is that I should not do what I was trying to do.

I can't even imagine the complexity of what a static final LoggerContext would look like if an EJB were distributed to another machine in the cluster. Objects like LoggerContext don't belong as members, static or not, of container-managed objects like EJBs.

It's not even clear that EJBs are the right implementation technology for what I am trying to build. My use cases are not really transactional so the case for EJB implementation is not strong so one possible path leads away from EJBs altogether.

The real message is that if EJBs or other container-managed components are indicated, it's probably best to use the container-provided logging system. I like log4j2, but until JBoss supports it, it's best to stick with container-provided log4j1 or some other framework.