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.
Modules should not assume they know about the structure of the NB installation. If they *must* use external files supplied in the NBM, the safest thing is to query the code source of the module JAR. Failing that, search in ${netbeans.home} - a dir ${netbeans.user} - a dir ${netbeans.dirs} - if set, some dirs, separated by File.pathSeparator Attaching sample (untested) fix for Tomcat40DataObject; Tomcat40Installation looked complicated, will need to be fixed in a more complicated way.
Created attachment 7913 [details] Example patch (for T40DO only)
The Tomcat module uses netbeans.home and netbeans.user for two different purposes: 1) In Tomcat40DataObject - some modules and libraries shipped with the IDE must be copied to the Tomcat installation. This provides some tightly integrated functionality, e.g. HTTP monitoring. The files are: lib/ext/pbclient.jar modules/ext/httpmonitor.jar modules/schema2beans.jar modules/ext/monitor-valve.jar modules/ext/tomcat40-ide.jar I don't think the patch you are suggesting would work, since each of the files above may reside in a different directory, e.g. one in netbeans.home and another in netbeans.user, and in the future, yet another one in one of netbeans.dirs. Calling Tomcat40DataObject.class.getProtectionDomain ().getCodeSource().getLocation() will give you the location for tomcat40.jar, which may be different from the others. Also, we may not want to load all of the above files into the VM by classloaders, as some are intended to be used only inside the server process. 2) In Tomcat40Installation, netbeans.home and netbeans.user are used to determine the location of the Tomcat installation bundled with the IDE (in directory ${netbeans.home}/tomcat404). From the ARCH point of view, this code should be moved to module tomcatint/bundledtomcat. ------ For us, the implementation could be most straightforward if there was an OpenIDE utility method which would determine the File location from a installation-relative path. This way, the introduction of netbeans.dirs could be easily handled just by local change in OpenIDE/core. Is this a viable option ?
Definitely agreed on #1 (sorry, did not notice these came from various modules) and probably on #2 (you know the code better than I). Re. having an API method to find an installation-relative path: I was thinking about this, but was not sure what would be most useful. One option is to define a URL protocol, e.g. nbinst:/modules/ext/monitor-valve.jar The problem is if you actually need it in File form for some reason - do you, or do you just need to open a URLConnection? Probably in some cases you do (e.g. constructing an external classpath). URLMapper in the Filesystems API does not help much, because these files will not generally be mounted. I filed issue #28683.
Fixed on Nov 14, 2002. Now using the new InstalledFileLocator instead of netbeans.home. Note that netbeans.user can not be equivalently replaced by InstalledFileLocator, because we ALWAYS want a user- specific directory - finding one in netbeans.home or netbeans.dirs is not enough. Is this ok, or should it somehow be replaced too ?
IFL is intended to be used for finding files shipped with a module. If you need to find a place in the user directory (e.g.) to put something new, there is still no supported API for that - this has not changed.
VERIFIED