Re: controlling ClassLoader when programmatically invoking Ant
I'll probably have to see some code to understand what's going on, but reflection will prevent classcast exceptions when accessing methods of a class loaded from a different class loader. From: Mitch Gitman To: Ant Developers List Sent: Sunday, July 22, 2012 8:52 AM Subject: Re: controlling ClassLoader when programmatically invoking Ant Right, what you describe falls under the #1 option I'd mentioned: "1. Create a parent ClassLoader just for all the Ant libraries and put JUnit itself and the entire test classpath in a child classloader." Considering that the code in question consists of JUnit tests that I WANT to run from within an IDE and that I NEED to run from Ant, together with producing the customary reports, this could get complicated pretty fast. Right now, I'm pursuing my option #3, the complications for which are: * Creating a URLClassLoader that uses a scaled-down analog to the Launcher URLClassLoader. * Deploying a JAR containing nothing but the custom BuildListener and BuildLogger to Ant lib. * Accessing the Project and custom BuildListener and BuildLogger using strictly reflection in the Ant test runner code. On Sun, Jul 22, 2012 at 5:27 AM, Vimil Saju wrote: > >So this time I actually did this. I created this parentless ClassLoader > and > >created a Project object from it. And what happened? The moment I tried to > >assign this object to a Project variable, I got a ClassCastException: > >org.apache.tools.ant.Project cannot be cast to > >org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. > > > I think to prevent class-cast issue, you should first create a class with > just a static main method, then use the parentless class loader to create > an instance of this class and invoke its main method through reflection. > All the ant related code should be then written in then main method of > the class that you created. > > The reason you are getting the class-cast exception is because you are > creating the Project object using say classloaderA and then trying to > access that object from a class that was loaded from another classloader. > > > > From: Mitch Gitman > To: Ant Developers List > Sent: Saturday, July 21, 2012 6:16 PM > Subject: Re: controlling ClassLoader when programmatically invoking Ant > > Quick update for anyone who's curious. > > I'd forgotten that I'd asked much the same question on the ant-user list > back on May 31. This was back when the contamination of the child classpath > with the parent classpath was literally causing the tests to fail. And same > as with this thread, Nicolas L. was kind enough to respond. See thread, > "example of correctly consuming an Ant project programmatically." > > What's funny (and sad in a way) is that today I went down much the same > path I had laid in the earlier thread without even recollecting that > thread. Here's what I wrote earlier: > *** > The one way I may have to tweak this ... is to do: > new URLClassLoader(jars, null); > > Passing null for the extra ClassLoader argument obviates the possibility of > the parent classloader creeping in. > *** > So this time I actually did this. I created this parentless ClassLoader and > created a Project object from it. And what happened? The moment I tried to > assign this object to a Project variable, I got a ClassCastException: > org.apache.tools.ant.Project cannot be cast to > org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. > > I also tried just calling Project.setCoreLoader() with this URLClassLoader, > but that didn't change the way the Ivy JAR and such were being loaded. > > At this point, I can think of a few ways to address this problem: > 1. Create a parent ClassLoader just for all the Ant libraries and put JUnit > itself and the entire test classpath in a child classloader. > 2. Run the Launcher class with the sandboxed ClassLoader and have a build > listener and build logger write the messages and out/err to the filesystem. > Then to do the assertions, read the files after the fact. > 3. Obtain an Object instance rather than a Project instance and use > reflection to call the few methods I have to call on it. > > #1 scares me! #2 is defeating much of the purpose of doing all this > programmatically. #3 ain't pretty, but so far it seems doable. > >
Re: controlling ClassLoader when programmatically invoking Ant
Right, what you describe falls under the #1 option I'd mentioned: "1. Create a parent ClassLoader just for all the Ant libraries and put JUnit itself and the entire test classpath in a child classloader." Considering that the code in question consists of JUnit tests that I WANT to run from within an IDE and that I NEED to run from Ant, together with producing the customary reports, this could get complicated pretty fast. Right now, I'm pursuing my option #3, the complications for which are: * Creating a URLClassLoader that uses a scaled-down analog to the Launcher URLClassLoader. * Deploying a JAR containing nothing but the custom BuildListener and BuildLogger to Ant lib. * Accessing the Project and custom BuildListener and BuildLogger using strictly reflection in the Ant test runner code. On Sun, Jul 22, 2012 at 5:27 AM, Vimil Saju wrote: > >So this time I actually did this. I created this parentless ClassLoader > and > >created a Project object from it. And what happened? The moment I tried to > >assign this object to a Project variable, I got a ClassCastException: > >org.apache.tools.ant.Project cannot be cast to > >org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. > > > I think to prevent class-cast issue, you should first create a class with > just a static main method, then use the parentless class loader to create > an instance of this class and invoke its main method through reflection. > All the ant related code should be then written in then main method of > the class that you created. > > The reason you are getting the class-cast exception is because you are > creating the Project object using say classloaderA and then trying to > access that object from a class that was loaded from another classloader. > > > > From: Mitch Gitman > To: Ant Developers List > Sent: Saturday, July 21, 2012 6:16 PM > Subject: Re: controlling ClassLoader when programmatically invoking Ant > > Quick update for anyone who's curious. > > I'd forgotten that I'd asked much the same question on the ant-user list > back on May 31. This was back when the contamination of the child classpath > with the parent classpath was literally causing the tests to fail. And same > as with this thread, Nicolas L. was kind enough to respond. See thread, > "example of correctly consuming an Ant project programmatically." > > What's funny (and sad in a way) is that today I went down much the same > path I had laid in the earlier thread without even recollecting that > thread. Here's what I wrote earlier: > *** > The one way I may have to tweak this ... is to do: > new URLClassLoader(jars, null); > > Passing null for the extra ClassLoader argument obviates the possibility of > the parent classloader creeping in. > *** > So this time I actually did this. I created this parentless ClassLoader and > created a Project object from it. And what happened? The moment I tried to > assign this object to a Project variable, I got a ClassCastException: > org.apache.tools.ant.Project cannot be cast to > org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. > > I also tried just calling Project.setCoreLoader() with this URLClassLoader, > but that didn't change the way the Ivy JAR and such were being loaded. > > At this point, I can think of a few ways to address this problem: > 1. Create a parent ClassLoader just for all the Ant libraries and put JUnit > itself and the entire test classpath in a child classloader. > 2. Run the Launcher class with the sandboxed ClassLoader and have a build > listener and build logger write the messages and out/err to the filesystem. > Then to do the assertions, read the files after the fact. > 3. Obtain an Object instance rather than a Project instance and use > reflection to call the few methods I have to call on it. > > #1 scares me! #2 is defeating much of the purpose of doing all this > programmatically. #3 ain't pretty, but so far it seems doable. > >
Re: controlling ClassLoader when programmatically invoking Ant
>So this time I actually did this. I created this parentless ClassLoader and >created a Project object from it. And what happened? The moment I tried to >assign this object to a Project variable, I got a ClassCastException: >org.apache.tools.ant.Project cannot be cast to >org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. I think to prevent class-cast issue, you should first create a class with just a static main method, then use the parentless class loader to create an instance of this class and invoke its main method through reflection. All the ant related code should be then written in then main method of the class that you created. The reason you are getting the class-cast exception is because you are creating the Project object using say classloaderA and then trying to access that object from a class that was loaded from another classloader. From: Mitch Gitman To: Ant Developers List Sent: Saturday, July 21, 2012 6:16 PM Subject: Re: controlling ClassLoader when programmatically invoking Ant Quick update for anyone who's curious. I'd forgotten that I'd asked much the same question on the ant-user list back on May 31. This was back when the contamination of the child classpath with the parent classpath was literally causing the tests to fail. And same as with this thread, Nicolas L. was kind enough to respond. See thread, "example of correctly consuming an Ant project programmatically." What's funny (and sad in a way) is that today I went down much the same path I had laid in the earlier thread without even recollecting that thread. Here's what I wrote earlier: *** The one way I may have to tweak this ... is to do: new URLClassLoader(jars, null); Passing null for the extra ClassLoader argument obviates the possibility of the parent classloader creeping in. *** So this time I actually did this. I created this parentless ClassLoader and created a Project object from it. And what happened? The moment I tried to assign this object to a Project variable, I got a ClassCastException: org.apache.tools.ant.Project cannot be cast to org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. I also tried just calling Project.setCoreLoader() with this URLClassLoader, but that didn't change the way the Ivy JAR and such were being loaded. At this point, I can think of a few ways to address this problem: 1. Create a parent ClassLoader just for all the Ant libraries and put JUnit itself and the entire test classpath in a child classloader. 2. Run the Launcher class with the sandboxed ClassLoader and have a build listener and build logger write the messages and out/err to the filesystem. Then to do the assertions, read the files after the fact. 3. Obtain an Object instance rather than a Project instance and use reflection to call the few methods I have to call on it. #1 scares me! #2 is defeating much of the purpose of doing all this programmatically. #3 ain't pretty, but so far it seems doable. On Sat, Jul 21, 2012 at 9:33 AM, Mitch Gitman wrote: > Nicolas, thanks. I was one class off. I was looking at Main and AntMain > when I should have been looking at Launcher. Seeing the type names and the > main method threw me off. And this corroborates my brief follow-up that I > could be doing something with URLClassLoader. Better for me to try to > leverage Launcher though than reinvent that wheel. > > Let me see how far I get with that. > > I do have to take issue with the one point you make: "But If I were you, I > wouldn't bother trying to mimic Ant classloading in a unit test. The > important thing is to be sure that you run against the expected version of > Ant and Ivy." > > First, this is not a unit test. It's an integration test or a functional > test, and if it doesn't emulate the real-life behavior in the wild, then > what use is it? > > Even if we are treating this as a unit test, you can't really say that > inadvertently picking up everything in the parent ClassLoader is the > equivalent of mocking or stubbing services and components as one normally > does when creating pure unit tests. Consider that there could be a ton of > classes in the IDE's ClassLoader that have nothing whatsoever to do with > the Ant Project being executed. > > And this brings me to my last concern. I have already encountered a > problem where some static functionality in some superfluous classes in the > IDE-inherited ClassLoader was causing the JUnit-invoked Project build to > fail. > > Even so, to my mind, the uncontrolled success I'm seeing now is no less > troubling than the uncontrolled failure I was seeing then. If you're a > biologist conducting an experiment, you don't want to find out your > cultures were growing only because the Petri dish got contaminated. > > On Sat, Jul 21, 2012 at 6:10 AM, Nicolas Lalevée < > nicolas.lale...@hibnet.org> wrote: > >> Hi Mitch, >> >> Le 21 juil. 2012 à 07:37, Mitch Gitman a écrit : >> >> > Technically
Bug report for Ant [2012/07/22]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 5003|Opn|Blk|2001-11-21|exec task does not return after executed command f| | 6606|Opn|Enh|2002-02-21|META-BUG problems with delegating classloaders| | 7712|New|Enh|2002-04-03|Provide patternset support for VSSGET task? | | 8294|New|Enh|2002-04-19|: Allow and to app| | 8866|New|Enh|2002-05-07|Signal handling in java task | | 8895|New|Enh|2002-05-08|ant and/or antcall should support forking | | 8972|New|Enh|2002-05-10|allow property expansion in property v| | 8981|New|Enh|2002-05-10|Tar task command additional features | | 9294|New|Enh|2002-05-21|[PATCH] optional/j2ee/ServerDeploy OC4J Support | | 9784|New|Enh|2002-06-11|BuildNumber task: make more extendable... | | 9995|Ass|Enh|2002-06-19|MKS Source Integrity tasks| |10020|New|Enh|2002-06-19|'s dependency behaviour should be more con| |10231|New|Enh|2002-06-25|Need access to current file in SQLExec| |10283|New|Enh|2002-06-27|Add a destfile to the uptodate task | |10402|New|Enh|2002-07-02|adding the ability of html like whitespace preserv| |3|New|Enh|2002-07-24|keytool task | |11560|Opn|Enh|2002-08-08|Taskdef does not apply reverseLoader policy on sta| |12267|New|Enh|2002-09-03|Add ability to unzip into separate folders| |12292|New|Enh|2002-09-04|[PATCH] enable tag inside tar| |12334|New|Enh|2002-09-05|REQUEST: Ant task doesn't allow attachment of a bu| |12518|New|Enh|2002-09-11|Gunzip & BUnZip2 add filesets, patternsets, and ov| |12765|New|Enh|2002-09-18|"rmdir" and "deltree" patches for ftp task enhance| |12964|New|Enh|2002-09-24|ANTLR only takes one input file at a time | |13047|Inf|Enh|2002-09-26|Support for and on O| |13048|New|Enh|2002-09-26|Add an optional containsall attribute to LineConta| |13371|New|Enh|2002-10-07|[PATCH] Contributed new CvsExportDiff task| |13847|New|Nor|2002-10-22|pvcs task: wrong option (-r) specified for get (sh| |13934|New|Enh|2002-10-24|Translate task shouldn't load default locale prope| |13939|New|Enh|2002-10-24|Translate task should have better key matching cap| |14320|New|Enh|2002-11-06|copy fileset followsymlinks="false" does not copy | |14393|New|Enh|2002-11-08|Support use of jndi within ant| |14512|New|Enh|2002-11-13|Allow creating database connection similar to with does not spot bad symlin| |15149|New|Enh|2002-12-06|Replace task | |15244|New|Enh|2002-12-10|tar task should be able to store symbolic links as| |15430|New|Enh|2002-12-17|Enhancement to ReplaceRegExp.java | |15596|New|Enh|2002-12-21|Identity mapper in uptodate task. | |15729|Ass|Nor|2002-12-31|StarTeam rootLocalFolder should be java.io.File | |15747|New|Enh|2003-01-01|change tasks (e.g. Ant) to take urls as well as fi| |15853|New|Enh|2003-01-07|Allow to plug-in different XML Catalog resolver in| |15949|Opn|Enh|2003-01-10|please provide links to docs.xml and jakarta-site2| |16131|New|Enh|2003-01-15|not possible to suppress "BUILD SUCCESSFUL" messag| |16255|New|Enh|2003-01-20|XmlLogger without DOM tree| |16427|New|Enh|2003-01-26|Output return value of setLastModified/document be| |16469|New|Enh|2003-01-27|Apply task should allow parallel execution on diff| |16494|New|Enh|2003-01-28|[PATCH] accessibility of Ant documentation| |16562|New|Enh|2003-01-29|Can not accept characters from keyboard in a thre| |16860|New|Enh|2003-02-06|Silent or Debug a single target | |16896|New|Enh|2003-02-07|Support in ProjectHelper / ProjectHelperImpl to op| |17074|New|Enh|2003-02-14|Contribution for WLSTOP | |17181|New|Nor|2003-02-18|Build fails while trying to get VSS files by label| |17372|New|Enh|2003-02-25|Enhancement of replace Task | |17742|New|Maj|2003-03-06|PVCS task generates GET with promotion group incor|
