> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > The "package" a class belongs to really is not just the package name, > but the pair of package name and the classloader that has loaded the > class.
Only when a package is sealed, no? Are you saying that you can't have two classes from the same package loaded by two different classloaders? I was not aware of this restriction. Can you point to a specific VM spec? > When we run "ant test", our testcases are in a nested <classpath>. > This means the tests get loaded by a separate AntClassLoader that is a > child of the classloader that has loaded Ant itself. Right. Up to here I'm following. But ClassLoader delegation kicks in, and the Ant classes the tests depend on are loaded thru the parent loader. (at least that was my understanding) > Usually this doesn't matter in your own projects since the classes you > want to test are also loaded by a child loader - only that in our case > the classes under test are special. Counldn't we just use the ignore Ant classes switch, for tests, and put the compiled Ant classes on the classpath? That would simplify things a lot, no? > A better solution might be to add build/classes to <junit>'s > <classpath> as well and somehow force ther AntClassLoader to not > delegate to the parent. I'm not sure this would be a sane option, > though. You'd end up with plenty of classes that have been loaded > twice in a single classloader hierarchy. Forking + explicit classpath, as described above, is much simpler a model, no? --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
