This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[r34 jul 16] AntProjectSupport deserializes itself by deser'ing a FileObject and a File. The File is fine, I suppose. However the FileObject checks the Repository for mounts. If the mount has not been set up by the time the APS is deserialized, apparently it can become invalid (fo==null, file==null) even though if deser'd later it would be fine. How I see this in r34 jul 16 JDK 1.4.0_01 Linux: 1. In sampledir, create Rara.java, dummy class. Create foo.xml, default target just echoes "Foo". Create bar.xml, default target just echoes "Bar". 2. Create a new project "foo-p" and switch to it. Mount sampledir. In Options, create a new Indirect Ant Compilation type, call it "foo comp". Configure Script to be foo.xml using "..." button. Also set Default Compiler on Java Sources to "foo comp". 3. Similarly, make "bar-p" with "bar comp" as default compiler running "bar.xml". 4. Switch back and forth between foo-p and bar-p. In each, click Rara and click Compile. Should print either "Foo" or "Bar" depending on current project. In my tests, it seems to work fine for a while. Once it printed "Bar" in foo-p, but I cannot reproduce this; Dieter's message (see URL) suggests this problem might occur more regularly for some people. Then it started throwing an NPE from TargetExecutor (will attach), which I think means that the AntProjectCookie had null file & fo both. I will attach a suggested debugging patch for relevant classes. It seems that AntProjectSupport should be more careful deserializing FileObject's, since the FileSystem's they come from might not yet be mounted. Suggestions: 1. Store file system name and resource path, just like AbstractFileObject.Replace does, and manually look up the right FileObject on demand (when getFileObject() is actually called). Change in ser format, so would need some code to ensure it could still read old APS ser data. 2. Keep ser format as it is. Change getFileObject() from this: public FileObject getFileObject () { if (fo != null && ! fo.isValid ()) { // #11065 AntModule.err.log (ErrorManager.WARNING, "AntProjectSupport fo=" + fo + " was not valid, clearing"); fo = null; } return fo; } to this: public FileObject getFileObject () { if (fo != null && ! fo.isValid ()) { // #11065 FileObject nuefo; if (file != null) { // workaround for project switch nuefo = findFileObject(file); } else { nuefo = null; } if (nuefo == null) { AntModule.err.log (ErrorManager.WARNING, "AntProjectSupport fo=" + fo + " was not valid, clearing"); } fo = nuefo; } return fo; } Maybe that will help, by falling back to finding the File in mounted filesystems (admittedly a hack, because it will work strangely if the File exists in more than one filesystem - the Script property might appear to "migrate" from one to the other after a project switch, though not after a restart I think).
Created attachment 6733 [details] stack trace of NPE
Created attachment 6734 [details] Suggested debugging patch (not patch to solve bug)
When I switch the project and try to compile Rara.java I always get the NPE and "Script" property of "[foo|bar] comp" is always "<missing Ant script>".
Created attachment 6755 [details] patch
Attached is patch for this problem. I decided to implement your first suggestion. Could you please skim it and let me know if you have some objections? Thanx.
The exception message from IndirectAntCompilerType is not quite right... perhaps it should rather say: # {0} - node display name # {1} - display name of compiler type The object {0} is configured to use {1} but the build script can no longer be found. updateFileObject() as written is wrong: if FSIE is thrown, then fileName != null && fsName == null, so resolveFileObject will throw NPE etc. If FSIE is thrown make sure you null out *both* variables. getNameExt() is also wrong - you want getPackageNameExt('/','.') I think. Otherwise the patch looks right to me. Does it work?
Created attachment 6783 [details] patch2
Created attachment 6784 [details] zip file with "modules/ant.jar"
Thanx Jesse, apart from getNameExt() I implemented your comments. getNameExt() according to JavaDoc "Getter for name and extension of a file object. Dot is used as separator between name and ext.". The patch works fine. Before I commit it into CVS I would like to ask Dieter if he could donwload the attached zip file containing ant.jar file and put it into his NB3.4B3 (into modules folder) and try whether his problem was fixed as well. Based on feedback I will commit and apply for integration into NB3.4.
I installed the patch instead the original jar file, delete the compiler, delete the projects (not completly ...) create all new but the problem I have is not solved. But the problem with NPE for really new projects seems to be solved. Maybe my problem is because I created the projects with an older NB (NB3.4B1, I guess). If I can help you with any other information, please ask me.
getNameExt() is not correct AFAIK - it does not include the folder path, only the name of the file object within its folder! I assume you did not test the patch using a build.xml in a subdirectory of the root of a mounted filesystem, only directly in the root. FileSystem.findResource expects the full path of course.
Target milestone was changed from '3.4' to TBD.
Maybe we should integrate the known patch and merge it, since there is a reproducible NPE solved by it, and Dieter can open a fresh bug for his problem if he can provide steps to reproduce it.
OK, I will fix it in the trunk and test it as much as I can and can try to ask for nb34 integration. Again I'm in favor of puting the fix into NB 3.4.1. I don't think this is showstopper. Although it is serious problem it had to be there for a long time. The functionality (projects & indirect compiler) is simply not used by users what means that they will not miss it if it won't work, otherwise this defect would be filed long time ago. But I will try to get it into NB34.
I'm going to further test it. You were of course right Jesse that getNameExt must be used. Fixed in files: Checking in src/org/apache/tools/ant/module/run/Bundle.properties; new revision: 1.13; previous revision: 1.12 Checking in src/org/apache/tools/ant/module/run/IndirectAntCompilerTyp new revision: 1.7; previous revision: 1.6 Checking in src/org/apache/tools/ant/module/xml/AntProjectSupport.java new revision: 1.19; previous revision: 1.18
Diff URLs: <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/mo dule/run/Bundle.properties.diff?r1=1.12&r2=1.13> <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/mo dule/run/IndirectAntCompilerType.java.diff?r1=1.6&r2=1.7> <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/mo dule/xml/AntProjectSupport.java.diff?r1=1.18&r2=1.19> The fix was reviewed by Jesse. It is integrated in trunk and was tested by Milan.
I think that this bug is not stopper for release34 (only stoppers can be intagrated now), since it's there very long time. Fix should be integrated to post-release34 release. Should we mention it in Release notes?
Mentioning it in RELNOTES make sense. Putting Patrick on cc:.
David or Jesse, could you provide a brief description and a workaround (if applicable)?
Brief? That will be problem.... If an AntIndirectCompiler is used in the project and the build script defined in the AntIndirectCompiler lies on the filesystem mounted in the project, after switching to this project in NetBeans the link to build script will be invalid and must be set again. There is no workaround. If user does not switch projects in NB this problem will not happen. If NB IDE is started with this project, the problem will not happen - it happens only when you switch to project. If the build script lies outside of the mounted filesystems the problem will not happen.
Here is my attempt to shorten this: "If you use indirect Ant compilation in a project and the build script defined in the AntIndirectCompiler lies on the filesystem mounted in the project, the link to the build script will become invalid if you switch to another project and then switch back to that project. You will need to reset the link to the build script every time you switch back to that project. This problem will not occur if you never switch projects or if the build script is not in a mounted filesystem."
Another qualification to add to the release notes: The problem only occurs if you explicitly customize Indir Ant Comp to point to a specific build script. Its default behavior is to search for a build.xml in the directory in which the file to be compiled resides, or the nearest parent directory up the file tree containing a build.xml file. (This behavior is akin to Ant's regular -find switch.) This default behavior should be unaffected by #25701, because I.A.C. will find the build.xml from scratch each time it is run, so a project switch is irrelevant.
Could easily be added to an update release I guess.
Link to diffs: <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/module/run/Bundle.properties.diff?r1=1.12&r2=1.13> <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/module/run/IndirectAntCompilerType.java.diff?r1=1.6&r2=1.7> <http://ant.netbeans.org/source/browse/ant/src/org/apache/tools/ant/module/xml/AntProjectSupport.java.diff?r1=1.18&r2=1.19>
Diffs look OK to me. For the future Repository.findResource is not good to use - will be pretty useless with disk roots mounted, so prefer to use e.g. FileUtil.{to,from}File, or just trust that FileObject serialization is more robust under the uni filesystem. But this minor comment does not matter at all for 3.4.
Integrated in NB341. (Jesse, thanx for the note about Rep.fR)
removing RELNOTE keyword since this has been fixed
Closed