Bug 108140 - incomplete CLASSPATH prevents unit tests from running
incomplete CLASSPATH prevents unit tests from running
Status: CLOSED WONTFIX
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-27 17:48 EST by Vadim Nasardinov
Modified: 2007-04-18 12:58 EDT (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Vadim Nasardinov 2003-10-27 17:48:12 EST
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
s_config.require("ccm-core/runtime.properties");

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
waf.runtime.jdbc_url=jdbc\:postgresql\:cat?user\=postgres

Resin makes sure the conf/ directory is available to its
classloader.

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

System.err.println
    ("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

$CCM_DEV_HOME/core/build/classes
$CCM_DEV_HOME/core/build/sql
$CCM_DEV_HOME/core/pdl
$CCM_DEV_HOME/core/build/tests/classes

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 18:22:09 EST
as of 37410, $CCM_HOME/conf is in the build.xml classpath 
Comment 2 Vadim Nasardinov 2003-10-28 10:09:12 EST
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
  BUILD FAILED
  The <property> task doesn't support the "classpathref" attribute.


This is for
    <property classpathref="ccm.base.classpath"
resource="/ccm-core/runtime.properties"/>

I checked the manual and this attribute does seem to be supported
http://ant.apache.org/manual/CoreTasks/property.html

I have ant-1.5-5jpp installed.

What version of Ant are you running?
Comment 3 Vadim Nasardinov 2003-10-28 11:40:59 EST
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"
     resource="ccm-core/runtime.properties"/>

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");
 83    
 84    // XXX not doing dependency sort here yet
 85    
 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    }
 93    
 94    inits.close();
 95     

On my system, the following initializers are registered:

    # select class_name from inits;
               class_name           
    --------------------------------
     com.arsdigita.core.Initializer
     com.arsdigita.cms.Initializer
    (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:

$CCM_DEV_HOME/core/build/classes
$CCM_DEV_HOME/core/build/sql
$CCM_DEV_HOME/core/pdl
$CCM_DEV_HOME/core/build/tests/classes
$CCM_DEV_HOME/conf

Missing from this is

$CCM_DEV_HOME/cms/build/classes


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
initialized.
Comment 4 Vadim Nasardinov 2003-10-29 09:25:25 EST
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-17 23:11:37 EDT
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 18:22:53 EST
closing old CCM bugs

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