Description of problem: The above mentioned tools use -D log4j.configuration in order to pass a URI to the location of the log4j configuration file. According to log4j documentation , when the log4j configuration file is being looked up, it should use this argument, however this is not the behavior as introduced at JBOSS EAP 6.1 - https://docs.jboss.org/author/display/AS72/Logging+Configuration#LoggingConfiguration-PerdeploymentLogging Our tools use the log4j jar files as shipped with jboss eap 6.1, so downstream this occurs. Bare in mind that in upstream, the version is JBoss AS 7.1.x (while 7.2 is the base to EAP 6.1). Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
We should consider to ship log4j jars that are not provided by JBoss EAP 6.1
In my opinion the solution crafted by Martin Perina [1] is good. It is already used by engine-manage-domains and by the notifier, only needs to be applied to engine-config. The other alternative would be to replace the org.apache.log4j module used by the application server, and that would probably generate more issues than it solves. [1] http://gerrit.ovirt.org/17840
(In reply to Juan Hernández from comment #2) > In my opinion the solution crafted by Martin Perina [1] is good. It is > already used by engine-manage-domains and by the notifier, only needs to be > applied to engine-config. > > The other alternative would be to replace the org.apache.log4j module used > by the application server, and that would probably generate more issues than > it solves. > > [1] http://gerrit.ovirt.org/17840 Hi Juan, But this is workaround... right? it should work without this[1] change in regular log4j usage. It also works fine in Fedora... If there is a problem in this regard and we workaround, wouldn't there more hidden issues? Thanks,
The problem will appear on JBoss 7.2 (EAP 6.1), it has nothing to do with Fedora or RHEL. Currently oVirt works with JBoss 7.1 so it's fine, but RHEVM 3.3 and RHEVM 3.2.3 will be deployed on JBoss EAP 6.1, that's the problem. I think we have several possibilities: 1) Use current patches - they will work fine unless some more changes appears in next versions of JBoss Log Manager log4j 2) Force JBoss to use original log4j library - not sure if possible and it will probably reveal some other problems 3) Replace log4j with Java Logging API - this should be investigated if feasible 4) Extract jars for engine-config, engine-manage-domains and engine-notifier from JBoss deployment and package them as standard java standalone application - IMHO probably best long term solution But the problem is in JBoss Log Manager log4j, they reimplemented foreign library and intentionally removed some functionality, didn't provide any easy way how application can detect this. I've never seen such problematic idea in all 17 years of my Java experience.
The solution without the workaround consists on using different module repositories for the tools and for the engine, so that tools can use an unmodified version of log4j without affecting the application server. The changes required to implement this are here: http://gerrit.ovirt.org/18222 http://gerrit.ovirt.org/18223 http://gerrit.ovirt.org/18224 http://gerrit.ovirt.org/18225
Note that the last change in this collection is reverting the changes to implement custom log4j configuration in the tools.
It has been decided to use the solutions described in the following bugs: Bug 984581 - There is no notifier.log generation Bug 994191 - [rhevm-manage-domains] /var/log/ovirt-engine/engine-manage-domains.log doesn't exist Bug 996962 - [engine-config] /var/log/ovirt-engine/engine-config.log doesn't exist The alternative changes have been abandoned and I am closing this bug. *** This bug has been marked as a duplicate of bug 994191 ***