Bug 996909 - java based tools (notifier, manage-domains, config) have logging issues
java based tools (notifier, manage-domains, config) have logging issues
Status: CLOSED DUPLICATE of bug 994191
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-config (Show other bugs)
3.3.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.2.4
Assigned To: Juan Hernández
Ilanit Stein
infra
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-14 05:25 EDT by Yair Zaslavsky
Modified: 2016-02-10 14:02 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-27 05:27:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 18224 None None None Never

  None (edit)
Description Yair Zaslavsky 2013-08-14 05:25:10 EDT
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:
Comment 1 Yair Zaslavsky 2013-08-14 05:26:39 EDT
We should consider to ship log4j jars that are not provided by JBoss EAP 6.1
Comment 2 Juan Hernández 2013-08-14 06:54:41 EDT
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
Comment 4 Alon Bar-Lev 2013-08-15 13:39:35 EDT
(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,
Comment 5 Martin Perina 2013-08-16 04:00:53 EDT
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.
Comment 6 Juan Hernández 2013-08-16 13:25:15 EDT
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
Comment 7 Juan Hernández 2013-08-16 13:26:20 EDT
Note that the last change in this collection is reverting the changes to implement custom log4j configuration in the tools.
Comment 8 Juan Hernández 2013-08-27 05:27:08 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.