Description of problem:
Determines which library c3p0 will output log messages to. By default, if log4j is available, it will use that library, ...
We do not have com.mchange.v2.log.MLog set, and following package versions are installed:
Hibernate fails to initialize with: java.lang.ClassNotFoundException: com.mchange.v2.log.MLog
Version-Release number of selected component (if applicable):
always on Fedora 15
Steps to Reproduce:
1. Install Spacewalk (https://fedorahosted.org/spacewalk/) on Fedora 15
2. Navigate to Spacewalk WebUI
HTTP Status 404 -
type Status report
description The requested resource () is not available.
This is caused by hibernate initialization failure due to java.lang.ClassNotFoundException: com.mchange.v2.log.MLog
log4j would be used by default causing no exceptions
Seems that replacing the /usr/share/java/c3p0.jar
resolves the problem
Until now we used
without any issues. Now the Fedora 15 c3p0 version has higher version and gets installed instead of the jpackage version.
# rpm -q c3p0
# rpm -ql c3p0
it seems that c3p0 isn't correctly packaged.
I would expect /usr/share/java/c3p0.jar to be a symlink to /usr/share/java/c3p0-0.9.0.2.jar
Due to this bug, Spacewalk on Fedora 15 is unusable. Please, check it.
Do you have mchange-commons installed?
I'm experiencing the same problem.
(In reply to comment #1)
> Do you have mchange-commons installed?
Yes, I do.
(In reply to comment #0)
> Description of problem:
> Seems that replacing the /usr/share/java/c3p0.jar
> resolves the problem
This ugly solution works for me as well.
mchange-commons is no longer bundled in c3p0. This should be addressed in spacewalk-java. Following change fixed that for me:
ln -s /usr/share/java/mchange-commons.jar /var/lib/tomcat6/webapps/rhn/WEB-INF/lib
We have the fix/workaround in Spacewalk, bug 732350.
Seeing Fedora will not put mchange-commons back to c3p0, let's just WONTFIX this one.
And what about the packaging problem?
(I would expect /usr/share/java/c3p0.jar to be a symlink to
(In reply to comment #5)
> And what about the packaging problem?
> (I would expect /usr/share/java/c3p0.jar to be a symlink to
No, actually Java packaging guidelines currently state that /usr/share/java/c3p0.jar is correct path for this jar. Versioned jars were abolished some time ago. They were not serving any machine purpose, because anyone who needs the jar should use unversioned version anyway. Otherwise an update of said jar could break his application.
If you want to know what version is the jar you can just do:
$ rpm -qf /usr/share/java/c3p0.jar
All right. Stanislav, thank you for explanation.