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.
Build: NetBeans Ruby IDE 20071109065752 VM: Java HotSpot(TM) Client VM, 1.5.0_13-119 OS: Mac OS X, 10.5, i386 User Comments: I asked "Find usages" for remove_unloadable_constants!, defined in dependencies.rb of Active Support, subversion revision 8125 of Rails
Created attachment 52830 [details] stacktrace
Fixed in trunk (commit log below). However, I'm wondering if we shouldn't backport this to 6.0 too. Basically, any attempt to refactor (in particular, Find Usages) a file in the "system directories" (file in the standard Ruby library, files under site_dir, and anything in rubygems such as Rails) will just result in an exception dialog. The scenario I used was to Open Type (ctrl-o), jump to #render (the method in ActionController::Base), and do a Find Usages. The NPE results. This has never worked, so it's surprising that it hasn't shown up as a bug report before, but I definitely think this will crop up as people discover Find Usages, and I think it's an important scenario to support. I'm CC'ing Jiri to see if QA agrees with the severity of this; if so I will bump it to P1 and file an integration notice. I'm CC'ing Martin so he can review my diffs (I will attach separately and then add an explanation. I'm CC'ing Petr since he is monitoring bugs in this area during high resistance. IDE:------------------------------------------------- IDE: [11/10/07 9:13 AM] Committing started Checking in projects/src/org/netbeans/modules/ruby/rubyproject/BootClassPathProvider.java; /cvs/ruby/projects/src/org/netbeans/modules/ruby/rubyproject/BootClassPathProvider.java,v <-- BootClassPathProvider.java new revision: 1.5; previous revision: 1.4 done Checking in platform/src/org/netbeans/api/ruby/platform/RubyInstallation.java; /cvs/ruby/platform/src/org/netbeans/api/ruby/platform/RubyInstallation.java,v <-- RubyInstallation.java new revision: 1.36; previous revision: 1.35 done IDE: [11/10/07 9:13 AM] Committing finished
Marking fixed in Dev/6.1.
Created attachment 52835 [details] Backport of trunk fix to the release60 branch
Here's an explanation of the fix for Martin's code review (and anyone else from the reviewer team): BACKGROUND: Files must be associated with a "class path" in order to be refactored properly. A Class Path is similar to the Java concept - it's a set of directories that are used to locate related files. Refactoring relies on this to determine which files to search for matches. All files in projects are automatically assigned the class path for the corresponding project. However, the "system files" (files in the Ruby libraries, Ruby Gems, under the users $GEM_HOME or around their chosen Ruby interpreter etc.) are NOT in a user project, so I have a special ClassPathProvider which recognizes these files: BootClassPathProvider.java . This class path provider looks at the file and determines if it's under either $GEM_HOME, or the user's Ruby interpreter, or the NetBeans Ruby cluster. It does this by calling RubyInstallation's "isSystemFile" method, which returned true/false if a file is in one of the system dirs. This worked fine for the common case this code is involved in: Determining the class path for a directory (which is done at every NetBeans startup). However, the provider did not work right when called on individual files (not folders). This is because that part of the provider was accidentally left unimplemented. THE FIX: There are two parts to the fix. In RubyInstallation, change the "isSystemFile" method from a boolean method, to a method which instead of returning true for system files returns the actual system root the file is under. The method is otherwise the same; if it used to return false, it now returns null, and if it used to return true, it now returns non null. In BootClassPathProvider, I modified the logic which used to see if we have a folder, and if not just return null. Now, if it's not a folder, it will use the system root as the folder instead and proceed as before. The net result is that for folders, the behavior of the BootClassProvider is the same as it was before. For files, instead of returning null, it now returns the system root for files in one of the system directories. (The diff also removes some comments left behind by the unfinished code.)
Thanks for nice explanation. I've learned another piece of a new code ;) If the affected code was not used from other places, than fix seems OK to me. Just a small thing. Since RubyInstallation#getSystemRoot always returns a directory, the second check in BootClassPathProvider#getRubyClassPaths: line 89: 'if (file.isFolder()) {'; seems to be redundant, since 'file' is always non-null folder. Might be just 'assert file.isFolder()' for the case something changes in the future.
Now that's a quick reaction to a bug report :-). The error did not happen working with a system file, the setup is a bit unusual: * I have Rails Edge under $HOME/src/rails_edge. * The RubyNetBeans project is a Rails application that has a symlink vendor/edge to that directory. * The action I described in the report was performed there. Does that give more context? Please feel free to ask as many information as needed, I'll be pleased to help.
Thanks for the quick review Martin, I agree to change the check to an assertion. Thanks for your info "fxn". Can you grab the latest build and check if the new build works for you? http://deadlock.netbeans.org/hudson/job/ruby/ I'm not sure if it will work with the symlink approach though. However, I think that's going to be a much less common scenario so I'm not sure we need to push a fix for that separate scenario into 6.0 - but I'd still like to fix it. Can you try it and see if you get better results? If not, I need to see how the symlink resolution kicks in and try to make it work, and at a minimum prevent the NPE (which itself isn't hard, but I'd rather fix it such that the actual find usages operation has appropriate context and can succeed.)
I tried the most recent build ATM, #5160. With a symlinked vendor/edge I get NullPointerException at org.netbeans.core.startup.layers.ArchiveURLMapper.getURL With a regular directory vendor/edge (that is, close RNB, remove the symlink, move the original directory beneath vendor, reopen RNB) I get the same exception. I didn't submit any data from within the IDE because I suppose it would open a new ticket, I can do that if you want.
I verified the fix in trunk and I agree to merge it into release60. To fxn: Please, try to open your project *without* symlink in NetBeans IDE with clean userdir. If you get an exception, please submit a new issue. Or if you get the exception only with symlink, submit issue as well. Thank you.
Done. I got the exception with a real directory vendor/edge. There was a clean svn export there. I deleted the project and created a new one just for this test. This is the new ticket: http://statistics.netbeans.org/exceptions/detail.do?id=11196 Best, -- fxn
Merged to 6.0 branch: Checking in platform/src/org/netbeans/api/ruby/platform/RubyInstallation.java; /cvs/ruby/platform/src/org/netbeans/api/ruby/platform/RubyInstallation.java,v <-- RubyInstallation.java new revision: 1.35.2.1; previous revision: 1.35 done Checking in projects/src/org/netbeans/modules/ruby/rubyproject/BootClassPathProvider.java; /cvs/ruby/projects/src/org/netbeans/modules/ruby/rubyproject/BootClassPathProvider.java,v <-- BootClassPathProvider.java new revision: 1.4.2.1; previous revision: 1.4 done
Changing priority to P1 and adding the 60_HR_FIX keyword.
Verified in NB 6.0.