Bug 110984 - The classpath used for WAF contains JARs for applications that are not even part of the server instance
The classpath used for WAF contains JARs for applications that are not even p...
Status: CLOSED RAWHIDE
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dennis Gregorovic
Jon Orris
:
: 112981 (view as bug list)
Depends On:
Blocks: 106481 110923
  Show dependency treegraph
 
Reported: 2003-11-26 06:23 EST by Daniel Berrange
Modified: 2007-04-18 12:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-26 17:37:40 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 Daniel Berrange 2003-11-26 06:23:35 EST
Description of problem:
Consider a system on which the following application RPMs are installed:

ccm-auth-http-1.4.1-1
ccm-cms-6.1.0-1
ccm-cms-types-address-6.1.0-1
ccm-cms-types-agenda-6.1.0-1
ccm-cms-types-article-6.1.0-1
ccm-cms-types-event-6.1.0-1
ccm-cms-types-faqitem-6.1.0-1
ccm-cms-types-filestorageitem-6.1.0-1
ccm-cms-types-formitem-6.1.0-1
ccm-cms-types-formsectionitem-6.1.0-1
ccm-cms-types-glossaryitem-6.1.0-1
ccm-cms-types-job-6.1.0-1
ccm-cms-types-legalnotice-6.1.0-1
ccm-cms-types-minutes-6.1.0-1
ccm-cms-types-motditem-6.1.0-1
ccm-cms-types-mparticle-6.1.0-1
ccm-cms-types-newsitem-6.1.0-1
ccm-cms-types-organization-6.1.0-1
ccm-cms-types-pressrelease-6.1.0-1
ccm-cms-types-relatedlink-6.1.0-1
ccm-cms-types-service-6.1.0-1
ccm-core-6.1.0-1
ccm-forum-1.4.1-1
ccm-ldn-aplaws-1.9.1-1
ccm-ldn-atoz-1.0.0-1
ccm-ldn-dublin-1.4.1-1
ccm-ldn-freeform-1.4.1-1
ccm-ldn-navigation-1.4.1-1
ccm-ldn-portal-1.4.1-1
ccm-ldn-rss-1.4.1-1
ccm-ldn-search-1.4.1-1
ccm-ldn-shortcuts-1.4.1-1
ccm-ldn-subsite-1.4.1-1
ccm-ldn-util-1.4.1-1
ccm-ldn-xmlfeed-1.4.1-1
ccm-simplesurvey-1.4.1-1

Now consider, setting up a server instances containing two applications:

<ccm:project name="aplaws-dev"
       prettyName="aplaws-dev"
       ccmVersion="6.1"
      xmlns:ccm="http://ccm.redhat.com/ccm-project">

  <ccm:build>
    <ccm:application name="myapp" prettyName="myapp" buildOrder="1"/>
  </ccm:build>

  <ccm:prebuilt>
    <ccm:application name="ccm-cms" version="6.1.0" buildOrder="1"/>
    <ccm:application name="ccm-core" version="6.1.0" buildOrder="1"/>
  </ccm:prebuilt>
</ccm:project>

If you then run 'ccm load' for example, it has all the JARs for all
installed applications in the CLASSPATH, even though only two of them
are actually configured in this server.

This is because ccm.classpath globs everything in /usr/share/java 
rather than just the bits it needs. 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:
Classpath contains JARs for all installed applications

Expected results:
Classpath contains JARs only for applications in the server instance.

Additional info:

This will cause particular problems if /usr/share/java contains
multiple versions of the same application / 3rd party JAR.

This caused peculiar errors when diagnosing bug 110923
Comment 1 Dennis Gregorovic 2003-12-16 12:43:12 EST
In my local checkout I have build-template.xsl and
classpath-template.xsl modified so that instead of including
/usr/share/java, they include /usr/share/java/<required jar>.  For
example, ccm-core has 

/usr/share/java/ccm-tools.jar
/usr/share/java/httpunit.jar
/usr/share/java/junit.jar
/usr/share/java/servletapi4.jar
                                                                     
                                                      
The list of required jars comes from the ccm:requires tags in
application.xml.  Note that this isn't perfect because there is no
ccm-tools.jar.  Still, it's probably a better approach than what we
have now.

Also, this doesn't address deployment installs or prebuilt
applications.  However, we can fix those two scenarios by including
application.xml with the RPM and using it in the %post script for
/etc/ccm/ccm.classpath and by
build-template.xsl/classpath-template.xsl for
$CCM_DEV_HOME/{build.xml,ccm.classpath}

Dan, what do you think?
Comment 2 Daniel Berrange 2003-12-18 05:43:13 EST
Ok, so we've got a domain mismatch in the uses of ccm:dependancies
here really. Originally I intended it to just list build time
dependancies on other CCM applications. We've expanded this to include
dependancies on 3rd RPMs such as junit, httpunit, etc. We're now
trying to extend that still further by assuming that the package name
corresponds to a JAR name & thus adding JARs to the classpath. If we
use it to generate /etc/ccm/ccm.classpath, this will also be extending
it further to list run time dependancies.

As far as I'm aware, we don't need anything form /usr/share/java
included in the classpath for a runtime production system. All the
depenadant libs are already in /usr/share/java/ccm-core/*.jar

So we've got the scenarios:

 * Generate the ant build order 'depends' attribute on <target>
 * Development build time 3rd party jars junit, httpunit, servletapi,
mockobjects, JavaCC.
 * RPM dependancies on CCM apps

To resolve this, I think its  time to start using the
ccm:buildRequires tag in addition to ccm:requires. buildRequires would
list any 3rd party JARs required. requires would list deps on CCM
applications only. So for CMS, for example,

    <ccm:requires name="ccm-core" version="6.1.0" relation="ge"/>
    <ccm:buildRequires name="httpunit" version="1.5.1" relation="ge"/>
    <ccm:buildRequires name="junit" version="3.8" relation="ge"/>
    <ccm:buildRequires name="servlet" version="2.3" relation="ge"/>

Does the ccm-tools line really need to be here, or can we put it
straight into the rpm.spec.in template file instead ?
Comment 3 Dennis Gregorovic 2003-12-18 10:28:05 EST
> As far as I'm aware, we don't need anything form /usr/share/java
> included in the classpath for a runtime production system. All the
> depenadant libs are already in /usr/share/java/ccm-core/*.jar

We do depend on servlet.jar when not running inside of a servlet
container (e.g. ccm load).  Also, we depend on classes12.jar.  For the
latter, our scripts attempt to automatically add it to the CLASSPATH.
 We could do the same for servlet.jar.  However, I wonder if there
will be more cases that need special treatment like this.

> To resolve this, I think its  time to start using the
> ccm:buildRequires tag in addition to ccm:requires. buildRequires 
> would list any 3rd party JARs required.

I like this idea.  Just to be clear: these items would be added to the
RPM spec as BuildRequires lines, right?

> requires would list deps on CCM applications only.

Again, I am concerned about runtime dependencies on 3rd party
libraries that are not included in the application, such as
servlet.jar and classes12.jar.  In fact, one scenario that intrigues
me is where we removed all of the jars from //core-platform/dev/lib
and make them into build/runtime requirements of core.  However, I
think you are right that for now let's keep it simple and only list
CCM apps with the requires tag.

> Does the ccm-tools line really need to be here, or can we put it
> straight into the rpm.spec.in template file instead ?

makes sense to move it to rpm.spec.in


Comment 4 Dennis Gregorovic 2004-01-09 13:45:07 EST
*** Bug 112981 has been marked as a duplicate of this bug. ***
Comment 5 Dennis Gregorovic 2004-01-09 15:31:32 EST
changes checked in @39259

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