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.
I have been spent about about 8 hours (and many hours in the past) now overcoming what I feel are overly restrictive classpath loading rules built into the current NetBeans platform. It is so cumbersome to get the classpath and dependencies right, that it requires 8 pages of explanation as an example here: http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/classpath.html I am going to submit two enhancement requests related to two rules that I submit are overly restrictive and complete time-wasters for module developers. The first one is throwing an "IllegalStateException" if the application attempts to load a properties file from the default package. This practice is very common and very practical for deployed applications. In my case, I am attempting to integrate JacORB client code into a NetBeans module. When JacORB attempts to load the orb.properties assumed to be at the root of the classpath (default package), I get this IllegalStateException: java.lang.IllegalStateException: You are trying to access file: orb.properties from the default package. Please see http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/classpath.html#default_package at org.netbeans.ProxyClassLoader.printDefaultPackageWarning(ProxyClassLoader.java:539) at org.netbeans.ProxyClassLoader.getResource(ProxyClassLoader.java:312) at org.jacorb.config.JacORBConfiguration.loadPropertiesFromClassPath(JacORBConfiguration.java:587) at org.jacorb.config.JacORBConfiguration.init(JacORBConfiguration.java:232) at org.jacorb.config.JacORBConfiguration.<init>(JacORBConfiguration.java:143) at org.jacorb.config.JacORBConfiguration.getConfiguration(JacORBConfiguration.java:119) at org.jacorb.orb.ORB.set_parameters(ORB.java:1482) It appears that I am going to have to modify the JacORB source code now to have it load it from another package rather than having it present in a simple directory (like etc or lib) in a default package. Please eliminate this rule from the classloading logic or at least just print an informational warning message that states that you're loading something from a default package.
It _is_ an informational message: LOGGER.log(Level.INFO, null, new IllegalStateException(...)); Fixing JacORB to load from e.g. org/jacorb/config/ is the proper solution. As the JLS states: "Unnamed packages are provided by the Java platform principally for convenience when developing small or temporary applications or when just beginning development." If you prefer, you can reduce the log level on this component.
There is fantasy and there is reality...How many applications have a log4j properties file read from the default package out there? Application level properties file should be able to have a properties file at the root of the classpath (like in lib or some place it is easy to find) without an exception being logged. An informational message indicating that the default path is being used would be fine, but it should not shown as an error.
log4j is special-cased for now, pending a fix in upstream code. This _is_ shown as an informational message, to the log file only. An error would be displayed at WARNING or above. (The stack trace is necessary because otherwise it could be difficult to determine exactly which code was loading the resource.)
You're using an IllegalStateException(...) to get the stack trace though so it appears as an "exception" in the log. You could just put a the String result of a Thread.currentThread().getStackTrace() instead so it doesn't look like an exception. Having property files such as log4j.properties or jacorb.properties in the default package is not bad practice. In fact, we have tried putting log4j.properties in individual modules package space and it is a complete usability nightmare when you want to change logging parameters for the entire application. It is best from a user-focused perspective to have the property files available in one place so it is easy to find and edit them. I think that it is bad practice to put class files in the default package, but not property files. As an editorial comment: The NetBeans development team should seek to embrace the input from the user (customer) community and think about what makes the usability of the APIs and platform better rather than focusing just on the purity of the APIs and maintenace from a NetBean's platform perspective. Making the platform more usable/friendlier and using familiar and practical patterns will attract more developers to the platform.
Whether it looks like an exception or not doesn't really matter. The NB exception notifier is configured by default to display log records with a throwable and level >= WARNING in the GUI. This is INFO so it stays in the log. Plenty of other platform code uses INFO with a throwable to indicate potential problems (comparable to WARNING without a throwable) that may require stack traces to diagnose. (Cleaner would have been to treat WARNING with or without a throwable consistently, but we are stuck with this convention for historical reasons - dates back to ErrorManager.) log4j.properties should be in org/log4j/ along with everything else. In a large system with hundreds of modules maintained by different authors, the unnamed package should not be used for any purpose. There is no difference between classes and resources in this respect - both form part of the same namespace.
Is this still true for 6.8? I've been annoyed by this characteristic a year now having to look through thousands of lines of useless stack traces to find useful information in the NetBeans logs. Putting property files like log4j properties in different directories for every module is a BAD idea in practice despite the puritanical arguments. People configuring an application do not want to have to change a log4j property file in 80 different directories (the number of modules in our application). They just want to go to a high level directory like application/etc or application/config or application/lib to find the configuration files to change. Please add a command line option to turn off these annoying stacktraces or get rid of them altogether.
Was removed in b9732ab8def7, 70c9449b03a4, and 324595be51ad.
Hallelujah!