Bug 735460 - java.lang.ClassNotFoundException: com.mchange.v2.log.MLog
Summary: java.lang.ClassNotFoundException: com.mchange.v2.log.MLog
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 1.5
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jan Pazdziora
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space16 732350
TreeView+ depends on / blocked
 
Reported: 2011-09-02 17:38 UTC by Tomas Lestach
Modified: 2012-03-06 09:17 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-23 13:18:45 UTC


Attachments (Terms of Use)

Description Tomas Lestach 2011-09-02 17:38:01 UTC
Description of problem:

According to 
http://www.mchange.com/projects/c3p0/index.html#configuring_logging :

com.mchange.v2.log.MLog
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:
log4j-1.2.16-7.fc15.noarch
apache-commons-logging-1.1.1-15.fc15.noarch

Hibernate fails to initialize with: java.lang.ClassNotFoundException: com.mchange.v2.log.MLog


Version-Release number of selected component (if applicable):
c3p0-0.9.2-0.5.pre1.fc15.noarch

How reproducible:
always on Fedora 15

Steps to Reproduce:
1. Install Spacewalk (https://fedorahosted.org/spacewalk/) on Fedora 15
2. Navigate to Spacewalk WebUI
  
Actual results:
=====================================
HTTP Status 404 -

type Status report

message

description The requested resource () is not available.

Apache Tomcat/6.0.32
=====================================

This is caused by hibernate initialization failure due to java.lang.ClassNotFoundException: com.mchange.v2.log.MLog
(java.lang.NoClassDefFoundError: com/mchange/v2/log/MLog)

Expected results:
log4j would be used by default causing no exceptions

Additional info:
1)
Seems that replacing the /usr/share/java/c3p0.jar
with
http://mirrors.ibiblio.org/pub/mirrors/maven2/c3p0/c3p0/0.9.0.2/c3p0-0.9.0.2.jar
resolves the problem

2)
Until now we used
http://mirrors.dotsrc.org/jpackage/5.0/generic/free/RPMS/c3p0-0.9.1.2-2.jpp5.noarch.rpm
without any issues. Now the Fedora 15 c3p0 version has higher version and gets installed instead of the jpackage version.

2)
Looking at:
# rpm -q c3p0
c3p0-0.9.2-0.5.pre1.fc15.noarch
# rpm -ql c3p0
/etc/maven/fragments/c3p0
/usr/share/doc/c3p0-0.9.2
/usr/share/doc/c3p0-0.9.2/CHANGELOG
/usr/share/doc/c3p0-0.9.2/LICENSE
/usr/share/doc/c3p0-0.9.2/RELEASE_NOTES-c3p0-0.9.2-pre1
/usr/share/doc/c3p0-0.9.2/index.html
/usr/share/java/c3p0.jar
/usr/share/maven2/poms/JPP-c3p0.pom

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

3)
Due to this bug, Spacewalk on Fedora 15 is unusable. Please, check it.

Comment 1 Mat Booth 2011-09-07 08:30:34 UTC
Do you have mchange-commons installed?

Comment 2 Jan Vcelak 2011-09-12 15:24:49 UTC
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:
> 1)
> Seems that replacing the /usr/share/java/c3p0.jar
> with
> http://mirrors.ibiblio.org/pub/mirrors/maven2/c3p0/c3p0/0.9.0.2/c3p0-0.9.0.2.jar
> resolves the problem

This ugly solution works for me as well.

Comment 3 Jan Vcelak 2011-09-12 16:14:25 UTC
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

Comment 4 Jan Pazdziora 2011-09-23 13:18:45 UTC
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.

Comment 5 Tomas Lestach 2011-09-26 11:03:35 UTC
And what about the packaging problem?

(I would expect /usr/share/java/c3p0.jar to be a symlink to
/usr/share/java/c3p0-0.9.0.2.jar.)

Comment 6 Stanislav Ochotnicky 2011-09-26 11:16:06 UTC
(In reply to comment #5)
> And what about the packaging problem?
> 
> (I would expect /usr/share/java/c3p0.jar to be a symlink to
> /usr/share/java/c3p0-0.9.0.2.jar.)

No, actually Java packaging guidelines[1] 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

[1] https://fedoraproject.org/wiki/Packaging:Java#JAR_file_installation

Comment 7 Tomas Lestach 2011-09-26 11:28:31 UTC
All right. Stanislav, thank you for explanation.


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