RE: [PATCH] allow tomcat5 to compile/run with JDK1.3
ok, looked into cvs so forget that mail :)
> -Original Message-
> From: pero [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 05, 2003 4:20 AM
> To: 'Tomcat Developers List'
> Subject: RE: [PATCH] allow tomcat5 to compile/run with JDK1.3
>
>
> > Everyone will call JdkCompat.getJdkCompat() to get a
> > JdkCompat instance.
> > When JdkCompat is statically initialized, it determines which
> > implementation to load. Currently, it performs a check on
> > System.getProperty("java.version"). If the property starts
> > with 1.4 then
> > the Jdk14Compat class is loaded. Otherwise, the default
> > JdkCompat will
> > be loaded.
> >
> > So, this has the side effect that when jdk1.5(and beyond)
> comes out -
> > this will load the wrong version of the class. Should I ignore that
> > issue for now or create a better comparison?
>
> I don't know whether System.getProperty ("java.version")
> always returns the correct version, especially for non
> SUN-implementations. Perhaps it is better (for now) to
> perform the check on the actual need, meaning trying to
> invoke "file.toURI().toURL()" via Reflection and see if it
> works. This will give the safety that for JDK 1.5 the correct
> (i.e. 1.4) compat will be used. But this mechanism will get
> complicated if other methods with other dependencies are added. :(
>
> Really only my $0.02,
>
> Peter
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PATCH] allow tomcat5 to compile/run with JDK1.3
> Everyone will call JdkCompat.getJdkCompat() to get a
> JdkCompat instance.
> When JdkCompat is statically initialized, it determines which
> implementation to load. Currently, it performs a check on
> System.getProperty("java.version"). If the property starts
> with 1.4 then
> the Jdk14Compat class is loaded. Otherwise, the default
> JdkCompat will
> be loaded.
>
> So, this has the side effect that when jdk1.5(and beyond) comes out -
> this will load the wrong version of the class. Should I ignore that
> issue for now or create a better comparison?
I don't know whether System.getProperty ("java.version") always returns
the correct version, especially for non SUN-implementations. Perhaps it is
better (for now) to perform the check on the actual need, meaning trying
to invoke "file.toURI().toURL()" via Reflection and see if it works. This
will give the safety that for JDK 1.5 the correct (i.e. 1.4) compat will be
used. But this mechanism will get complicated if other methods with other
dependencies are added. :(
Really only my $0.02,
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] allow tomcat5 to compile/run with JDK1.3
Here is an attempt at a JdkCompat implementation. There are 2 classes,
JdkCompat which is the base support class and Jdk14Compat which extends
JdkCompat.
The patch is in JdkCompat.txt for WebappClassloader and build.xml. I
manually edited the patch file to eliminate all the extra edits my text
editor makes with respect to whitespace changes.
Everyone will call JdkCompat.getJdkCompat() to get a JdkCompat instance.
When JdkCompat is statically initialized, it determines which
implementation to load. Currently, it performs a check on
System.getProperty("java.version"). If the property starts with 1.4 then
the Jdk14Compat class is loaded. Otherwise, the default JdkCompat will
be loaded.
So, this has the side effect that when jdk1.5(and beyond) comes out -
this will load the wrong version of the class. Should I ignore that
issue for now or create a better comparison?
-Tim
Costin Manolache wrote:
Tim Funk wrote:
To get functionality like jdkCompat (and looking at tomcat3), it looks
like something similar to the following would need added to the existing
jakarta-tomcat-catalina/catalina/build.xml:
--
--
Where would jdkCompat live with respect to package name? Does it belong
in catalina? (org.apache.catalina.util.compat.ClassXXX)
I would place it in j-t-c/util, even in o.a.tomcat.util.compat ( but with a
different name than jkd11compat class in 3.3 ).
This kind of code is very common.
/*
* $Header: $
* $Revision: $
* $Date: $
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
*
Re: [PATCH] allow tomcat5 to compile/run with JDK1.3
Tim Funk wrote: > To get functionality like jdkCompat (and looking at tomcat3), it looks > like something similar to the following would need added to the existing > jakarta-tomcat-catalina/catalina/build.xml: > -- > unless="jdk.1.4.present"/> > -- > Where would jdkCompat live with respect to package name? Does it belong > in catalina? (org.apache.catalina.util.compat.ClassXXX) I would place it in j-t-c/util, even in o.a.tomcat.util.compat ( but with a different name than jkd11compat class in 3.3 ). This kind of code is very common. > Are there any other methods (wishlist) which need to be here? We can add as we go. You can do a grep in sources for all reflection - and see if anything else is needed there. > Or am I getting ahead of myself and should I be patient and wait for > someone with better insight to do this instead? You seem to have good insight, please do it. Costin > > -Tim > > > Remy Maucherat wrote: >> Costin Manolache wrote: >> >>> Tim Funk wrote: >>> >>> >>> Oh, NO. Please don't even think about it Commons-dbcp must do it >>> because >>> it is impossible to write a JDBC driver that works and compiles in >>> both 1.3 >>> and 1.4. >>> Reflection is fine - I would preffer using a jdkCompat-like trick and >>> have >>> substitute code for 1.3, but I'm fine with reflection. >> >> >> Yes, I agree using a compat class is definitely much nicer :) >> >> Remy >> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] allow tomcat5 to compile/run with JDK1.3
To get functionality like jdkCompat (and looking at tomcat3), it looks like something similar to the following would need added to the existing jakarta-tomcat-catalina/catalina/build.xml: -- unless="jdk.1.4.present"/> -- Where would jdkCompat live with respect to package name? Does it belong in catalina? (org.apache.catalina.util.compat.ClassXXX) Are there any other methods (wishlist) which need to be here? Or am I getting ahead of myself and should I be patient and wait for someone with better insight to do this instead? -Tim Remy Maucherat wrote: Costin Manolache wrote: Tim Funk wrote: Oh, NO. Please don't even think about it Commons-dbcp must do it because it is impossible to write a JDBC driver that works and compiles in both 1.3 and 1.4. Reflection is fine - I would preffer using a jdkCompat-like trick and have substitute code for 1.3, but I'm fine with reflection. Yes, I agree using a compat class is definitely much nicer :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] allow tomcat5 to compile/run with JDK1.3
Remy Maucherat wrote:
> Costin Manolache wrote:
>> Remy Maucherat wrote:
>>
>>
>>>Tim Funk wrote:
>>>
Tomcat5 does not compile with JDK1.3. It does with JDK1.4.
There is only one line of code that prevents it from compiling with
JDK1.3. org.apache.catalina.loader.WebappClassLoader depends on
File.toURI() which does not exist on jdk1.3.
I got around this by the performing the following:
OLD CODE:
return realFile.toURI().toURL();
NEW CODE
return new URL("file:" + realFile.toURL().getPath());
My patch also has some spurious stuff because my text editor
automatically strips all trailing whitespace from lines and converts
tabs to spaces. The important stuff is the last 9 lines of the patch
file.
>>>
>>>The patch is a bad idea. The change was made to fix RMI related problems.
>>>
>>>What should be done is invoke the appropriate methods through
>>>reflection, catching any error (and defaulting to the old code if it
>>>fails).
>>
>>
>> Well, reflection is a bad idea too :-) A better solution is to use a
>> wrapper like jdkCompat ( i.e. a base class with the 1.3 implementation,
>> extended with a 1.4 impl ). This class could include other 1.4 methods
>> and their 1.3 equivalent, if any.
>
> Well, I was planning to implement it as:
>
> try {
> // do the nasty 1.4 stuff with reflection
> } catch (Throwable t) {
> // do the compatible stuff
> }
>
> It's not nice but it works (and as the CL is cached, we don't care too
> much about the performance loss due to the exception).
It works - but programming control statements via exceptions is ugly.
And very likely the code will be cut&pasted in other places.
Having a base jdkCompat will allow this code to be reused and will be
cleaner ( IMO ).
Not a big deal...
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] allow tomcat5 to compile/run with JDK1.3
Costin Manolache wrote: Tim Funk wrote: Oh, NO. Please don't even think about it Commons-dbcp must do it because it is impossible to write a JDBC driver that works and compiles in both 1.3 and 1.4. Reflection is fine - I would preffer using a jdkCompat-like trick and have substitute code for 1.3, but I'm fine with reflection. Yes, I agree using a compat class is definitely much nicer :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] allow tomcat5 to compile/run with JDK1.3
Costin Manolache wrote:
Remy Maucherat wrote:
Tim Funk wrote:
Tomcat5 does not compile with JDK1.3. It does with JDK1.4.
There is only one line of code that prevents it from compiling with
JDK1.3. org.apache.catalina.loader.WebappClassLoader depends on
File.toURI() which does not exist on jdk1.3.
I got around this by the performing the following:
OLD CODE:
return realFile.toURI().toURL();
NEW CODE
return new URL("file:" + realFile.toURL().getPath());
My patch also has some spurious stuff because my text editor
automatically strips all trailing whitespace from lines and converts
tabs to spaces. The important stuff is the last 9 lines of the patch
file.
The patch is a bad idea. The change was made to fix RMI related problems.
What should be done is invoke the appropriate methods through
reflection, catching any error (and defaulting to the old code if it
fails).
Well, reflection is a bad idea too :-) A better solution is to use a
wrapper like jdkCompat ( i.e. a base class with the 1.3 implementation,
extended with a 1.4 impl ). This class could include other 1.4 methods
and their 1.3 equivalent, if any.
Well, I was planning to implement it as:
try {
// do the nasty 1.4 stuff with reflection
} catch (Throwable t) {
// do the compatible stuff
}
It's not nice but it works (and as the CL is cached, we don't care too
much about the performance loss due to the exception).
This would allow implementing the correct stuff, instead of failing.
Sure.
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] allow tomcat5 to compile/run with JDK1.3
Tim Funk wrote: > After looking at the older revisions, I agree my patch was stupendously > horrible :( > > The patch now uses reflection to keep the current code equivalent for > jdk14 and use the old way in case of a jdk1.3 jvm. > > That being said - I would assume that the RMI issue your patch addressed > would still be an issue in JDK1.3. Can you give me some insight on what > it was? If possible I can attempt to make the appropriate fix. > > I think commons-dbcp project do some wacky magic on java src files ( > poor man's equivalent of c directives for code include/exclude). Is that > an alternative to move towards for situations like this? Or is having > one and only one binary the a better goal? (So users don't need to > choose a 1.3 and 1.4 binary) Oh, NO. Please don't even think about it Commons-dbcp must do it because it is impossible to write a JDBC driver that works and compiles in both 1.3 and 1.4. Reflection is fine - I would preffer using a jdkCompat-like trick and have substitute code for 1.3, but I'm fine with reflection. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] allow tomcat5 to compile/run with JDK1.3
Remy Maucherat wrote:
> Tim Funk wrote:
>> Tomcat5 does not compile with JDK1.3. It does with JDK1.4.
>>
>> There is only one line of code that prevents it from compiling with
>> JDK1.3. org.apache.catalina.loader.WebappClassLoader depends on
>> File.toURI() which does not exist on jdk1.3.
>>
>> I got around this by the performing the following:
>> OLD CODE:
>> return realFile.toURI().toURL();
>> NEW CODE
>> return new URL("file:" + realFile.toURL().getPath());
>>
>> My patch also has some spurious stuff because my text editor
>> automatically strips all trailing whitespace from lines and converts
>> tabs to spaces. The important stuff is the last 9 lines of the patch
>> file.
>
> The patch is a bad idea. The change was made to fix RMI related problems.
>
> What should be done is invoke the appropriate methods through
> reflection, catching any error (and defaulting to the old code if it
> fails).
Well, reflection is a bad idea too :-) A better solution is to use a
wrapper like jdkCompat ( i.e. a base class with the 1.3 implementation,
extended with a 1.4 impl ). This class could include other 1.4 methods
and their 1.3 equivalent, if any.
This would allow implementing the correct stuff, instead of failing.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] allow tomcat5 to compile/run with JDK1.3
After looking at the older revisions, I agree my patch was stupendously
horrible :(
The patch now uses reflection to keep the current code equivalent for
jdk14 and use the old way in case of a jdk1.3 jvm.
That being said - I would assume that the RMI issue your patch addressed
would still be an issue in JDK1.3. Can you give me some insight on what
it was? If possible I can attempt to make the appropriate fix.
I think commons-dbcp project do some wacky magic on java src files (
poor man's equivalent of c directives for code include/exclude). Is that
an alternative to move towards for situations like this? Or is having
one and only one binary the a better goal? (So users don't need to
choose a 1.3 and 1.4 binary)
-Tim
Remy Maucherat wrote:
Tim Funk wrote:
Tomcat5 does not compile with JDK1.3. It does with JDK1.4.
There is only one line of code that prevents it from compiling with
JDK1.3.
org.apache.catalina.loader.WebappClassLoader depends on File.toURI()
which does not exist on jdk1.3.
I got around this by the performing the following:
OLD CODE:
return realFile.toURI().toURL();
NEW CODE
return new URL("file:" + realFile.toURL().getPath());
My patch also has some spurious stuff because my text editor
automatically strips all trailing whitespace from lines and converts
tabs to spaces. The important stuff is the last 9 lines of the patch
file.
The patch is a bad idea. The change was made to fix RMI related problems.
What should be done is invoke the appropriate methods through
reflection, catching any error (and defaulting to the old code if it
fails).
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: WebappClassLoader.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.13
diff -u -r1.13 WebappClassLoader.java
--- WebappClassLoader.java 13 Nov 2002 00:36:25 - 1.13
+++ WebappClassLoader.java 3 Feb 2003 12:59:09 -
@@ -65,6 +65,7 @@
import java.io.InputStream;
import java.io.ByteArrayInputStream;
import java.io.IOException;
+import java.lang.reflect.Method;
import java.net.JarURLConnection;
import java.net.MalformedURLException;
import java.net.URL;
@@ -109,22 +110,22 @@
/**
* Specialized web application class loader.
*
- * This class loader is a full reimplementation of the
+ * This class loader is a full reimplementation of the
* URLClassLoader from the JDK. It is desinged to be fully
* compatible with a normal URLClassLoader, although its internal
* behavior may be completely different.
*
- * IMPLEMENTATION NOTE - This class loader faithfully follows
- * the delegation model recommended in the specification. The system class
- * loader will be queried first, then the local repositories, and only then
- * delegation to the parent class loader will occur. This allows the web
+ * IMPLEMENTATION NOTE - This class loader faithfully follows
+ * the delegation model recommended in the specification. The system class
+ * loader will be queried first, then the local repositories, and only then
+ * delegation to the parent class loader will occur. This allows the web
* application to override any shared class except the classes from J2SE.
* Special handling is provided from the JAXP XML parser interfaces, the JNDI
- * interfaces, and the classes from the servlet API, which are never loaded
+ * interfaces, and the classes from the servlet API, which are never loaded
* from the webapp repository.
*
- * IMPLEMENTATION NOTE - Due to limitations in Jasper
- * compilation technology, any repository which contains classes from
+ * IMPLEMENTATION NOTE - Due to limitations in Jasper
+ * compilation technology, any repository which contains classes from
* the servlet API will be ignored by the class loader.
*
* IMPLEMENTATION NOTE - The class loader generates source
@@ -227,9 +228,9 @@
public WebappClassLoader(ClassLoader parent) {
super(new URL[0], parent);
-
+
this.parent = getParent();
-
+
system = getSystemClassLoader();
securityManager = System.getSecurityManager();
@@ -670,7 +671,7 @@
/**
* Return a String array of the current repositories for this class
* loader. If there are no repositories, a zero-length array is
- * returned.For security reason, returns a clone of the Array (since
+ * returned.For security reason, returns a clone of the Array (since
* String are immutable).
*/
public String[] findRepositories() {
@@ -705,7 +706,7 @@
((ResourceAttributes) resources.getAttributes(paths[i]))
.getLastModified();
if (lastModified != lastModifiedDates[i]) {
-
Re: [PATCH] allow tomcat5 to compile/run with JDK1.3
Tim Funk wrote:
Tomcat5 does not compile with JDK1.3. It does with JDK1.4.
There is only one line of code that prevents it from compiling with JDK1.3.
org.apache.catalina.loader.WebappClassLoader depends on File.toURI()
which does not exist on jdk1.3.
I got around this by the performing the following:
OLD CODE:
return realFile.toURI().toURL();
NEW CODE
return new URL("file:" + realFile.toURL().getPath());
My patch also has some spurious stuff because my text editor
automatically strips all trailing whitespace from lines and converts
tabs to spaces. The important stuff is the last 9 lines of the patch file.
The patch is a bad idea. The change was made to fix RMI related problems.
What should be done is invoke the appropriate methods through
reflection, catching any error (and defaulting to the old code if it fails).
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
