Re: [Patch] trying solve w2k command line length limitations
On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje Class.forName will use the system classloader and not the nice little IMHO This contradicts my experience of CLs, i think some places inside tomcat used Class.forName also, and never seen what you say.. Class.forName loads in the current loader Now, where did I get this misconception? Sorry I have disappointed you, DD ;-) I think what you say is true for Java 1.2+, but not for Java 1.1. The API docs of Java 1.1 are not clear about this, but a lot of classloader stuff has changed between 1.1 and 1.2. I'm one of those poor guys who still have to maintain 1.1 compatibility. So for Ant 1.6, this is no issue as long as no core Ant classes calling Class.forName can also be loaded via the parent. Stefan
RE: [Patch] trying solve w2k command line length limitations
I've solved that problem for my own purposes a few months ago, by just
hacking a bit at java.c, so it can read it's command line arguments from a
file, using the usual @file syntax (that Javac already supports, but
implemented in Java). Even enabled env. var. substitutions a la Ant, using
the ${env.VARNAME} syntax. You can even *set* env. var. within that command
line file, which is something I needed to debug JNI code from within Visual
Studio, to set the Path (using env. vars. to be location independent) to
find dependents of native libraries (since SUN apparently can't use
LoadLibraryEx as Steve L. pointed out). That hacked up java.exe (Windows
HACK only) find the right JDK as specified in the registry, which is just
normal behavior (didn't have to code that).
Never had a problem since... --DD
-Original Message-
From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 05, 2003 10:38 AM
To: '[EMAIL PROTECTED]'
Subject: [Patch] trying solve w2k command line length limitations
Hola a todos:
I'm trying to solve w2k command line length problems for gump.
what i've tried is to create a properties file from gump instead of
passing the classpath in the command line, make a Launcher class that
loads it in a URLclassloader and start ant's main, this approach by
itself doesnt work at all, javac needs real jars in a real classpath not
a CL with all the jars loaded..
Hence this patch, the Launcher in addition to create a UCL, adds a
system property ant.class.path and starts ant's Main.. i've modified ant
Path type to add this property to the classpath like it's done with
java.class.path ( this property is readonly ).., and if using
build.sysclasspath=only, this property contents are added in addition to
java.class.path..
Comments are welcomed..
Saludos,
Ignacio J. Ortega
Index: src/main/org/apache/tools/ant/types/Path.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/ant/types/Path.java,v
retrieving revision 1.47
diff -u -r1.47 Path.java
--- src/main/org/apache/tools/ant/types/Path.java 11 Mar 2003
10:57:42 - 1.47
+++ src/main/org/apache/tools/ant/types/Path.java 5 Apr 2003
16:28:25 -
@@ -103,6 +103,9 @@
public static Path systemClasspath =
new Path(null, System.getProperty(java.class.path));
+public static Path antClasspath =
+new Path(null, System.getProperty(ant.classpath));
+
/**
* Helper class, holds the nested codelt;pathelementgt;/code
values.
@@ -556,7 +559,8 @@
if (order.equals(only)) {
// only: the developer knows what (s)he is doing
result.addExisting(Path.systemClasspath, true);
-
+result.addExisting(Path.antClasspath, true);
+
} else if (order.equals(first)) {
// first: developer could use a little help
result.addExisting(Path.systemClasspath, true);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] trying solve w2k command line length limitations
Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] On Sat, 5 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: what i've tried is to create a properties file from gump instead of passing the classpath in the command line, make a Launcher class that loads it in a URLclassloader and start ant's main, Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? the problem i've found when using the URLCL approach, is more a problem of javac that didnt use resources loaded in the CL to compile, instead it needs a real classpath with jar or classfiles in it.. or i understand you badly? i've modified ant Path type to add this property to the classpath like it's done with java.class.path ( this property is readonly ).., and if using build.sysclasspath=only, this property contents are added in addition to java.class.path.. Which introduces a hole to defeat Gump, or any other setup that uses build.sysclasspath=only. I've not looked into the patch, but we'll have to ensure that ant.class.path will be set to java.class.path when the launcher has not been used - and do that before the user had a chance to set this property. How can i signal ant that is used by Launcher instead of directly? and the porpouse of the launcher is that precisely, to launch ant with a given classpath but not passing it in the command line, so how can ant set a property before the launcher ? -- Saludos, Ignacio J.Ortega Nevada Soft
RE: [Patch] trying solve w2k command line length limitations
FYI, Javac is not really using java.class.path, but env.class.path instead... By default, the former will be copied in the later by javac.c. Discovered this early 2001 when I wrote a little Java front-end to Javac to be Visual Studio friendly. Could be of use to the discussion??? --DD -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2003 9:41 AM To: [EMAIL PROTECTED] Subject: Re: [Patch] trying solve w2k command line length limitations Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] On Sat, 5 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: what i've tried is to create a properties file from gump instead of passing the classpath in the command line, make a Launcher class that loads it in a URLclassloader and start ant's main, Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? the problem i've found when using the URLCL approach, is more a problem of javac that didnt use resources loaded in the CL to compile, instead it needs a real classpath with jar or classfiles in it.. or i understand you badly? i've modified ant Path type to add this property to the classpath like it's done with java.class.path ( this property is readonly ).., and if using build.sysclasspath=only, this property contents are added in addition to java.class.path.. Which introduces a hole to defeat Gump, or any other setup that uses build.sysclasspath=only. I've not looked into the patch, but we'll have to ensure that ant.class.path will be set to java.class.path when the launcher has not been used - and do that before the user had a chance to set this property. How can i signal ant that is used by Launcher instead of directly? and the porpouse of the launcher is that precisely, to launch ant with a given classpath but not passing it in the command line, so how can ant set a property before the launcher ? -- Saludos, Ignacio J.Ortega Nevada Soft - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] trying solve w2k command line length limitations
Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? Class.forName will use the system classloader and not the nice little IMHO This contradicts my experience of CLs, i think some places inside tomcat used Class.forName also, and never seen what you say.. Class.forName loads in the current loader and delegates to parent if needed AFAIK, but i'm little far from the code.. now.. so i can be worng.. i'm not arguing only very surprised, and trying to get to speed in the related facts.. -- Saludos, Ignacio J.Ortega Nevada Soft
RE: [Patch] trying solve w2k command line length limitations
Stefan is *of course* right! Class.forName always uses the system class loader, and not some current loader... As far as delegation happening, that's ClassLoader 101. Unless of course one uses the second form of Class.forName, that takes a classloader as argument, provided one doesn't pass null for it, that is. Stefan was referring the first form, that takes only a class name. --DD -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2003 11:23 AM To: [EMAIL PROTECTED] Subject: Re: [Patch] trying solve w2k command line length limitations Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? Class.forName will use the system classloader and not the nice little IMHO This contradicts my experience of CLs, i think some places inside tomcat used Class.forName also, and never seen what you say.. Class.forName loads in the current loader and delegates to parent if needed AFAIK, but i'm little far from the code.. now.. so i can be worng.. i'm not arguing only very surprised, and trying to get to speed in the related facts.. -- Saludos, Ignacio J.Ortega Nevada Soft
RE: [Patch] trying solve w2k command line length limitations
Dominique Devienne writes: Stefan is *of course* right! Class.forName always uses the system class loader, and not some current loader. No it doesn't. It uses the defining class loader of the caller. http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Class.html#forName(java.lang.String) Andrew.
RE: [Patch] trying solve w2k command line length limitations
I stand corrected, and apologize. --DD -Original Message- From: Andrew Haley [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2003 11:53 AM To: Ant Developers List Subject: RE: [Patch] trying solve w2k command line length limitations Dominique Devienne writes: Stefan is *of course* right! Class.forName always uses the system class loader, and not some current loader. No it doesn't. It uses the defining class loader of the caller. http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Class.html#forName(java.la ng.String) Andrew.
Re: [Patch] trying solve w2k command line length limitations
Costin Manolache [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] The problem seems to be that we need a way to pass a CLASSPATH but without using the env variable. And this needs to have the override properties of the CLASSPATH that are used in gump. Well, the problem is the maximun command line length, not only the env size, if i understand you well.., later the env var is use as part of java command that launches ant from gump, and passing -D for ant in the command line has the exact same problem.. but the later is easy to overcome with a simple -propertyfile args to ant.. well to comment a bit more, the stupid cmd.exe, adds a blank space after every echo routed to a file.. so is a little more complicated.. :(.. Wouldn't be simpler to just add a bit of code to set java.class.path from a file or property ? If you go with a wrapper that embeds ant, that would be pretty simple and not need any changes to ant. I think i've tried modifying java.class.path, and ended at nowhere, i thought it was controlled to be read-only, not found any reference in JDK to the use of java.class.path, but reviewing my patch another time and given the name of the property i propose, maybe i confused java.class.path with java.classpath, so i'll try another time.. :) to see what happens.. Thanks to point this obvious issue.. :) -- Saludos, Ignacio J.Ortega Nevada Soft
Re: [Patch] trying solve w2k command line length limitations
Stefan Bodewig wrote: On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? Class.forName will use the system classloader and not the nice little URLClassLoader your Launcher provides. Many places inside Ant use Class.forName, thereby assuming that everything from ANT_HOME/lib will be available on the system classloader. My understanding is that Class.forName uses the current loader - i.e. the defining loader for the class - which for most tasks is the main AntClassLoader. So far using the ClassLoader task ( which just adds jars to the main loader ) seems to work fine and never run into any problem with Class.forName not finding something. I would also add the JBoss class loading scheme - which is also adding jars, with few twists to support reloading - is also working fine with Class.forName. ( yes, I know I need to write the docs for the loader task - this is the first thing I'll do after I finish with the current tasks ). Costin
Re: [Patch] trying solve w2k command line length limitations
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 07, 2003 11:33 Subject: Re: [Patch] trying solve w2k command line length limitations Stefan Bodewig wrote: On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? Class.forName will use the system classloader and not the nice little URLClassLoader your Launcher provides. Many places inside Ant use Class.forName, thereby assuming that everything from ANT_HOME/lib will be available on the system classloader. My understanding is that Class.forName uses the current loader - i.e. the defining loader for the class - which for most tasks is the main AntClassLoader. So far using the ClassLoader task ( which just adds jars to the main loader ) seems to work fine and never run into any problem with Class.forName not finding something. Ted Newards Understanding Class.forName() doc on develop.com is the reference guide here. I recall that stuff in JRE/lib/ext is on a separate classloader, and of course you can't find stuff belonging to subsidiary classloaders. Then there is the issue of the thread context classloader (thread.getContextClassLoader()), that does not get set properly on Sun ONE app server. It's a 1.2 feature so we've ignored it in ant till now. I would also add the JBoss class loading scheme - which is also adding jars, with few twists to support reloading - is also working fine with Class.forName. ( yes, I know I need to write the docs for the loader task - this is the first thing I'll do after I finish with the current tasks ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] trying solve w2k command line length limitations
- Original Message - From: Ignacio J. Ortega [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 05, 2003 08:37 Subject: [Patch] trying solve w2k command line length limitations Hola a todos: I'm trying to solve w2k command line length problems for gump. didnt know there were any, but it doenst surprise me what i've tried is to create a properties file from gump instead of passing the classpath in the command line, make a Launcher class that loads it in a URLclassloader and start ant's main, this approach by itself doesnt work at all, javac needs real jars in a real classpath not a CL with all the jars loaded.. I'll delegate assessment of the path to people who understand those bits of the code, but you should know that for ant1.6 we want to move to classloading stuff ourselves instead of faffing around with doing the jar file setup in the bat files, as we get far too many support calls related to those few lines of text. Integration of what ant1.6 does with your needs for Gump would seem good, plus any problems you've worked around are things we also need to deal with. i.e we dont necessarily need two launcher classes...
[Patch] trying solve w2k command line length limitations
Hola a todos:
I'm trying to solve w2k command line length problems for gump.
what i've tried is to create a properties file from gump instead of
passing the classpath in the command line, make a Launcher class that
loads it in a URLclassloader and start ant's main, this approach by
itself doesnt work at all, javac needs real jars in a real classpath not
a CL with all the jars loaded..
Hence this patch, the Launcher in addition to create a UCL, adds a
system property ant.class.path and starts ant's Main.. i've modified ant
Path type to add this property to the classpath like it's done with
java.class.path ( this property is readonly ).., and if using
build.sysclasspath=only, this property contents are added in addition to
java.class.path..
Comments are welcomed..
Saludos,
Ignacio J. Ortega
Index: src/main/org/apache/tools/ant/types/Path.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/ant/types/Path.java,v
retrieving revision 1.47
diff -u -r1.47 Path.java
--- src/main/org/apache/tools/ant/types/Path.java 11 Mar 2003
10:57:42 - 1.47
+++ src/main/org/apache/tools/ant/types/Path.java 5 Apr 2003
16:28:25 -
@@ -103,6 +103,9 @@
public static Path systemClasspath =
new Path(null, System.getProperty(java.class.path));
+public static Path antClasspath =
+new Path(null, System.getProperty(ant.classpath));
+
/**
* Helper class, holds the nested codelt;pathelementgt;/code
values.
@@ -556,7 +559,8 @@
if (order.equals(only)) {
// only: the developer knows what (s)he is doing
result.addExisting(Path.systemClasspath, true);
-
+result.addExisting(Path.antClasspath, true);
+
} else if (order.equals(first)) {
// first: developer could use a little help
result.addExisting(Path.systemClasspath, true);
