----- 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] > >
