tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James THOMAS" <James_THO...@enovia.com>
Subject Tomcat 3.3 (JDK 1.1 compatibility fixes)
Date Thu, 06 Sep 2001 20:09:04 GMT

Hello, I've provided below JDK 1.1 compatibility fixes for Tomcat 3.3.  Can
someone please add these fixes to the code?  I believe you'll find that the
fixes are trivial except for the last one.  The last problem I described
below concerns the way the class loaders are implemented.  I have a
solution that works but I think it needs to be verified.   Thank you for
your time.  James.



======================================================================
File:  jakarta-tomcat-3.3-dev-src\src\build.xml
======================================================================
Line:  301
Add the following line:
     <exclude name="**/util/depend/DependClassLoader12.java" unless
="jdk12.present"/>
Reason:
     We don't want to compile the class "DependClassLoader12" when JDK 1.1
is used to compile Tomcat 3.3

======================================================================
File:
jakarta-tomcat-3.3-dev-src\src\admin\WEB-INF\classes\tadm\AntTag.java
======================================================================
Line: 24
    targets.clear();
Change to:
    targets.removeAllElements();
Reason:
     The method "clear" does not exist on Vector class in JDK 1.1

======================================================================
File:
jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\startup\EmbededTomcat.java
======================================================================
Line:  198
     attributes.put( name, v );
Change To:
     if( v == null )
          attributes.remove( name );
     else
          attributes.put( name, v );
Reason:
     When running with JDK 1.1, the value of the "parentClassLoader" is
null, which will cause an exception because null values cannot be placed
into a hashtable.  As a generic solution, I recommend changing the
implementation to treat a "setAttribute" with a null value as a request to
remove the current attribute value.

======================================================================
File:
jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\startup\Main.java
======================================================================
Line: 215-216
     System.setProperty( "tomcat.home", installDir );
     System.setProperty("java.security.policy",  policyFile);
Change To:
     System.getProperties().put( "tomcat.home", installDir );
     System.getProperties().put("java.security.policy",  policyFile);
Reason:
     The method "setProperty" does not exist in JDK 1.1

======================================================================
File:
jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\util\compat\Jdk11Compat.java
======================================================================
Line: 142
     }while((cl!=null) && ( depth < c ));
Change To:
     }while((cl!=null) && ( depth >= c ));
Reason:
     The loop condition is incorrect.  This bug cause JSP compilation
errors because the classpath does not contain the common classpath (which
includes the servlet.jar).

======================================================================
File:
jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\util\depend\DependClassLoader.java
======================================================================
The method "loadClassInternal" appears to be incorrect.  When loading a
class, the code first retrieves the class as a resource from the "parent"
class loader.  But, the return value from the "getResource" is not used
because the code then delegates the class loading to the "parent2" class
loader ("parent2.loadClass(name)").  When running with JDK 1.1, the
"getResource" returns null because the "jar" protocol is not valid (the
exception message "unknown protocol: jar" is thrown from SimpleClassLoader
where a java.net.URL is constructed).  This causes the "loadClassInternal"
method to throw a "ClassNotFoundException" prematurely because the class
can successfully be loaded by one of the the parent class loaders.  Below I
offer a solution but I think it would be best if someone with a more
in-depth understanding of the code can validate this solution.

Side note: with the solution below, we can eliminate the need for the
"parent2" attribute held by the "DependClassLoader" class.

protected Class loadClassInternal( String name, boolean resolve )
      throws ClassNotFoundException
   {
      if( debug>0) log( "loadClass() " + name + " " + resolve);
      Class c = null;

      // check if  we already loaded this class
        c = findLoadedClass( name );
        if( c != null ) {
         //System.out.println( "class already loaded" );
           if( resolve )
            resolveClass( c );
         return c;
      }

      // check parent class
      if( parent != null ) {
         try {
            c = parent.loadClass( name );
            //System.out.println( "class loaded by parent" );
            return c;
         }
         catch( ClassNotFoundException e ) {
         }
      }

      throw new ClassNotFoundException(name);
   }


James Thomas
ENOVIA Corp.
704 - 944 - 8933
james_THOMAS@enovia.com


Mime
View raw message