Bug 108140 - incomplete CLASSPATH prevents unit tests from running
Summary: incomplete CLASSPATH prevents unit tests from running
Alias: None
Product: Red Hat Web Application Framework
Classification: Retired
Component: other   
(Show other bugs)
Version: nightly
Hardware: All Linux
Target Milestone: ---
Assignee: ccm-bugs-list
QA Contact: Jon Orris
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-27 22:48 UTC by Vadim Nasardinov
Modified: 2007-04-18 16:58 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-12-07 23:22:53 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Vadim Nasardinov 2003-10-27 22:48:12 UTC
I get the following error when trying to run CategorizationSuite on
the trunk (as of 37406 or so):
java.io.InputStream is null
c.a.util.AssertionError: java.io.InputStream is null
 at c.a.util.Assert.exists(Assert.java:179)
 at c.a.runtime.AbstractConfig.require(AbstractConfig.java:67)
 at c.a.runtime.RuntimeConfig.getConfig(RuntimeConfig.java:60)
 at c.a.tools.junit.extensions.BaseTestSetup.setUp(BaseTestSetup.java:94)
 at c.a.tools.junit.extensions.BaseTestSetup$1.protect(BaseTestSetup.java:71)

The offendingline in RuntimeConfig is

This tries to load the file "ccm-core/runtime.properties"
and fails, because the classloader can't find it.

The reason this same code doesn't fail in a running server is
because the file is deployed into the Resin's "conf" directory:

$ cat $CCM_HOME/conf/ccm-core/runtime.properties
# Generated by com.arsdigita.packaging.ConfigTool
#Mon Oct 27 16:07:00 EST 2003

Resin makes sure the conf/ directory is available to its

When running "ant -Djunit.suite=CategorizationSuite.class", all
we have is whatever Ant put on the classpath.  I added

    ("java.class.path=" + System.getProperty("java.class.path"));

before the point of failure.  After removing all the .jar and
.zip files, the classpath looks like so


One possible way to resolve this is change build.xml so that
runtime.properties gets copied someplace where the classloader
can find it.

Comment 1 Dennis Gregorovic 2003-10-27 23:22:09 UTC
as of 37410, $CCM_HOME/conf is in the build.xml classpath 

Comment 2 Vadim Nasardinov 2003-10-28 15:09:12 UTC
I grabbed the updated RPM from
http://park-street.boston.redhat.com/test/module-ccm-devel-dev.html this morning
and did
rpm -Uvh --replacepkgs --replacefiles ccm-devel-2.0.0-1.noarch.rpm
to pick up your fix.

It seems that my Ant is a bit old.  I'm getting
  The <property> task doesn't support the "classpathref" attribute.

This is for
    <property classpathref="ccm.base.classpath"

I checked the manual and this attribute does seem to be supported

I have ant-1.5-5jpp installed.

What version of Ant are you running?

Comment 3 Vadim Nasardinov 2003-10-28 16:40:59 UTC
I am reporting a different issue, but it falls under the same general
description, so I'm filing it here rather than opening a new ticket.
(Should be changed from from QA_READY to REOPENED.)

I temporarily hacked around the Ant issue reported in my previous
comment by changing the above-mentioned line like so:

<property classpath="/var/ccm-devel/web/vadim/dev/conf"

The unit tests can now progress a little further before blowing up
with the following exception:

java.lang.ClassNotFoundException: com.arsdigita.cms.Initializer
  at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
  at java.security.AccessController.doPrivileged(Native Method)
  at java.net.URLClassLoader.findClass(URLClassLoader.java:183)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
  at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310)
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:115)
  at com.arsdigita.util.Classes.loadClass(Classes.java:48)
  at com.arsdigita.util.Classes.newInstance(Classes.java:146)
  at com.arsdigita.runtime.Startup.<init>(Startup.java:92)
  at com.arsdigita.tools.junit.extensions.BaseTestSetup.setUp(BaseTestSetup.java:96)

This happens because the Startup class attempts the following:

$ p4 print //core-platform/dev/src/com/arsdigita/runtime/Startup.java#1 |
   grep -v //core | nl -ba - | head -n 95 | tail -n 15
 81    final DataCollection inits = session.retrieve
 82        ("com.arsdigita.runtime.Initializer");
 84    // XXX not doing dependency sort here yet
 86    while (inits.next()) {
 87        if (s_log.isDebugEnabled()) {
 88            s_log.debug("adding: " + (String) inits.get("className"));
 89        }
 90        add((Initializer) Classes.newInstance
 91                ((String) inits.get("className")));
 92    }
 94    inits.close();

On my system, the following initializers are registered:

    # select class_name from inits;
    (2 rows)

Note, however, that "com.arsdigita.cms.Initializer" is not on the
classpath, when I run 

$ ant -Djunit.suite=CategorizationSuite.class runtests

The (non-jar, non-zip) elements of the classpath are:


Missing from this is


Put a little more generally, the problem is that prior to the landing
of the test-packaging branch, we had a way of specifying the last
initializer that must be run.  At this point, the system attempts to
run all the registered initializers, regardless of the fact that I
want to run my unit test against core only - I don't CMS to be

Comment 4 Vadim Nasardinov 2003-10-29 14:25:25 UTC
The issue with the "classpathref" attribute not being supported
in some versions of Ant has been fixed by Dennis.  I p4 sync'ed
to //tools/ccmbuild/devel/dev/...@37456 or thereabouts and rebuilt
the ccm-devel RPM.  The build.xml file generated from the updated
build-template.xsl works fine now.

The issue with "com.arsdigita.cms.Initializer" seems to have
been fixed as well.  Don't remember what changelist fixed that
particular issue.

Comment 5 David Lawrence 2006-07-18 03:11:37 UTC
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future.
Moving to ON_QA.

Comment 6 Dennis Gregorovic 2006-12-07 23:22:53 UTC
closing old CCM bugs

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