We have the following requirements: There is a servlet that serves as a front end to many disparate EJBs. The servlet reads the request parameters , decides which EJB they tell it to invoke, invoke that EJB from a JNDI lookup on the server. Currently this is implemented on WebLogic, but we are trying to port it to JBoss. And we'd also like it to use log4j2 rather than log4j.
Both WebLogic and JBoss, and all application servers that I know of, have the same relationship to log4j: There is one Configuration per class loader. That seems to be an immutable rule. A Web App deployed in a War file has its own class loader. An enterprise application deployed in an EAR file has its own class loader. An EJB deployed as an EJB JAR seems to use the container's class loader. But here is the rub: We would like to have separate deployment of the EJBs. These deployments in our organization are wrapped in RPMs , and they deploy the JEE archive (WAR, EAR, or EJB JAR) to the server using some script contained in the RPM. Once deployed, the rpm postinstall script must also deploy the logging configuration file somewhere. In order to achieve this separate deployment of EJBs, we have basically two choices: 1) Maintain the logging configuration of the master servlet webapp manually, adding appenders and loggers to the configuration file that also contains loggers and appenders for all the other EJBs run from this servlet and separately from the deployment of the EJB itself. 2) Develop some sort of scheme where each EJB "owns" a temporary logging configuration file in an intermediate directory. When an RPM for one of the separately deployable EJBs is installed, launch a program that reads all the logging configuration files in the intermediate directory and writes out a new config file for the master servlet that includes the configs for all of these EJBs. In fact we have such a system already, written in-house many years ago, based on log4j-1.x. It's rather crude, but it works. Is there a better way to do this in log4j2? Is there a way to launch some sort of Builder that reads in a Configuration file, allows modification of the Configuration loaded and then writes the modified Configuration back to a disk file. This would then cause the LoggerContext to update itself. --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
