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.
Hello, we were hit by this problem when trying to deploy a module that connects as a client to the Sun App server. We had the problem once already and I have hardcoded some packages that we needed (search for comment containing "IBM"). I am proposing to use a system property listing such packages. Will attach patch shortly. Could this possible get into 5.0? It is a defect - at least in our application: not being able to specify the packages makes some of our modules fail with very strange exceptions. Thanks for an evaluation.
Yarda? I think we talked about this some time ago.
Created attachment 25250 [details] Proposed patch against trunk as of 20050928
I have implemented prefix comparison - we might also want to have there exact comparison if we want to improve performance. But for our application to start the proposed fix should be enough. Please comment (especially about the 5.0). BTW will the release50 be based on release50_beta or trunk?
Re: "BTW will the release50 be based on release50_beta or trunk?" Trunk. release50_beta is a dead end.
I would suggest that the 2-arg form of System.getProperty be used with the default value being "org/w3c/dom/,org/w3c/dom/ls/" or whatever is needed to remove the current hardcoded items. BTW this is an API of sorts so please go thru FAST_TRACK review, not that I am expecting any problems.
I suggest to leave the patch like it is now. The difference between the items that are passed from the system property is in that they are needed by application modules while the still hardcoded ones are needed by the core platform itself (if I am not mistaken). In other words the core will keep running ok whatever you pass in that system property. Moreover the test on the mentioned packages is for equals while I am testing for prefix for those coming from the property. It might be slower for the affected packages but gets rid of the nasty exceptions. I agree that this is an API but insist on the issue type being defect because it makes the paltform unusable for some jar configurations. Making the issue fast track API review - lets see whether we will get more comments.
I agree that we need a solution so generaly I am OK with the patch. Maybe I'd prefer static initializer to compute the list of special resources - it has to be done always and pretty soon and we can save some method calls. OTOH if you want to integrate the patch as it is we may profile it and tune later.
Radim, the patch already contains static cache for the prefixes. They will be computed only once. The next calls will just compare, no object allocations are done from the second call onwards ... should be pretty fast IMHO.
If there will be no objections I will apply the patch tomorrow.
Checking in arch/arch-core-launcher.xml; /cvs/core/arch/arch-core-launcher.xml,v <-- arch-core-launcher.xml new revision: 1.37; previous revision: 1.36 done Checking in startup/src/org/netbeans/core/startup/NbInstaller.java; /cvs/core/startup/src/org/netbeans/core/startup/NbInstaller.java,v <-- NbInstaller.java new revision: 1.19; previous revision: 1.18 done RCS file: /cvs/core/startup/test/unit/src/org/netbeans/core/startup/NbInstallerTest1.java,v done Checking in startup/test/unit/src/org/netbeans/core/startup/NbInstallerTest1.java; /cvs/core/startup/test/unit/src/org/netbeans/core/startup/NbInstallerTest1.java,v <-- NbInstallerTest1.java initial revision: 1.1 done
.
Sorry I don't get it. What was the purpose of this patch. If it was beeing able to use the property for specifying which packages should be loaded from modules classpath rather than from the JDK. Then it does not seem to work. I've tried to use the property but I still had (Except starting with Dorg.netbeans.core.startup.specialResource set to list of my packages) to put the package names into NbInstaller.CLASSPATH_PACKAGES.
isSpecialResource == package that can have classes in more jars. Nothing to do with JDK. It turns off the optimalization that forbids one package being loaded from more jars (package ownership).