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.
Summary: | AutoUpdate doesn't work after uninstall of module that provides its own AUC | ||
---|---|---|---|
Product: | platform | Reporter: | Lukas Hasik <lhasik> |
Component: | Autoupdate | Assignee: | Jiri Rechtacek <jrechtacek> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jchalupa, jglick, mmirilovic |
Priority: | P2 | Keywords: | RELNOTE |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 72435 | ||
Attachments: |
messages.log - looong
NPE when updatecenters module uninstalled a patch applicable in NB5.0/NB5.5 |
Description
Lukas Hasik
2006-02-01 07:19:50 UTC
Created attachment 28688 [details]
messages.log - looong
there is easy work around for this issue -Go to Tools | Options -switch to Advanced Options -collapse IDE Configuration | System | AutoUpdate Types -right click Java ME Platform SDK Catalog and Delete it -restart NetBeans -Update Center works again The same happens when uninstalling any module providing update center - for example org.netbeans.modules.updatecenters module Created attachment 28690 [details]
NPE when updatecenters module uninstalled
Too serious, it has to be fixed for NB.next changed Summary to be more generic. It appears after uninstall of any module that provided AutoUpdate Center to IDE Worksforme with NB5.0 RC2 if install/uninstall/restart IDE with Extra Update Centers module. Reproducible with NetBeans Update Centers module (which is a eager module and it's crucial maybe). Lukas, Adam, on what kind of module did you found this problem? Eager? Normal? Worksforme with nbextras module on NB5.0 FCS. Problems appears when an user uninstall some eager module, a eager module isn't correctly deleted from SFS cache. IMHO I can decrease the priority. Jesse, core/startup/ModuleList.stepDelete() cannot handle deletion of enabled eager module. Should be fixed in module system or should be restricted Uninstall of this kind of modules? Jesse, core/startup/ModuleList.stepDelete() cannot handle deletion of enabled eager module. Should be fixed in module system or should be restricted Uninstall of this kind of modules? "Should be fixed in module system or should be restricted Uninstall of this kind of modules?" - both (in the opposite order). It is not currently possible to delete an eager module while NB is running; would require changes in core of module system to support it. So Module Manager should not offer the possibility until that is done. *** Issue 72348 has been marked as a duplicate of this issue. *** *** Issue 72501 has been marked as a duplicate of this issue. *** *** Issue 72501 has been marked as a duplicate of this issue. *** *** Issue 72632 has been marked as a duplicate of this issue. *** Evaluation ========== How to reproduce (w/ mobility and also generally): 1. install Mobility pack via installer / add a module which declares Update Center 2. connect the Update Center what declared above 3.A uninstall Mobility pack via uninstaller (btw. IDE is not running while uninstalling) 3.B uninstall Mobility pack via Module Manager (btw. IDE is running), in general: remove the module which declares UC from installation 4. restart IDE 5. open Update Center Wizard or Options|Advanced options|Autoupdate Type ==> NPE is always thrown XMLAutoupdateType.getDefaultURL What's problem? The most important step to reproduction is "2. connect the Update Center" Why? Because when AutoUpdate successfully done connection then writes into AutoupdateType a timestamp of this connection. But this change of AutoupdateType setting is *put into userdir*. None of uninstallation can remove this record from userdir. AutoupdateType setting contains path to localizing bundle, a path is invalid if it's a abandoned setting of removed module. Conclusion: It's means it's a general problem which can appear always when removing a module which writes any settings into userdir. Not a problem of Module Manager, not a direct problem of Autoupdate code. Workaround: Remove the broken setting via Options|Advanced options|Autoupdate Types. However an user have to ignore thrown exceptions when removing this setting. Of course, an user can also delete userdir and start IDE w/ fresh dir. It is certainly a problem of the autoupdate module. The fact that we have a poor settings system is unfortunate but it is working as designed. autoupdate is at fault for storing transient information such as a last-connect time into AutoupdateType. It should keep this information somewhere else, e.g. in a SystemOption as e.g. a Map<String,Date> where the key is the AuT .settings file's getPath() in the system filesystem. Honzo note: another place where using Preferences would have avoided the bug to begin with... I know. We gotta do it. Hotfix of this problem was integrated in main trunk. This hotfix is applicable in NB5.5 To NB6.0 should be the Autoupdate settings handled better, tracked as issue 73180. Checking in autoupdate/src/org/netbeans/modules/autoupdate/AutoupdateType.java; /shared/data/ccvs/repository/autoupdate/src/org/netbeans/modules/autoupdate/AutoupdateType.java,v <-- AutoupdateType.java new revision: 1.18; previous revision: 1.17 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/Bundle.properties; /shared/data/ccvs/repository/autoupdate/src/org/netbeans/modules/autoupdate/Bundle.properties,v <-- Bundle.properties new revision: 1.173; previous revision: 1.172 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/XMLAutoupdateType.java; /shared/data/ccvs/repository/autoupdate/src/org/netbeans/modules/autoupdate/XMLAutoupdateType.java,v <-- XMLAutoupdateType.java new revision: 1.41; previous revision: 1.40 done Created attachment 29097 [details]
a patch applicable in NB5.0/NB5.5
Isn't the bundle key CTL_QuantumAutoupdateType_Name now unreferenced? *** Issue 73191 has been marked as a duplicate of this issue. *** *** Issue 73506 has been marked as a duplicate of this issue. *** Would not a small, little, simple test better than nothing? Otherwise ok, this is the safest direction to fix the problem compatibly. *** Issue 73903 has been marked as a duplicate of this issue. *** Backport in release55 branch. Checking in autoupdate/src/org/netbeans/modules/autoupdate/AutoupdateType.java; /shared/data/ccvs/repository/autoupdate/src/org/netbeans/modules/autoupdate/AutoupdateType.java,v <-- AutoupdateType.java new revision: 1.17.50.1; previous revision: 1.17 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/Bundle.properties; /shared/data/ccvs/repository/autoupdate/src/org/netbeans/modules/autoupdate/Bundle.properties,v <-- Bundle.properties new revision: 1.158.2.3.2.1; previous revision: 1.158.2.3 done Checking in autoupdate/src/org/netbeans/modules/autoupdate/XMLAutoupdateType.java; /shared/data/ccvs/repository/autoupdate/src/org/netbeans/modules/autoupdate/XMLAutoupdateType.java,v <-- XMLAutoupdateType.java new revision: 1.32.6.2.2.2; previous revision: 1.32.6.2.2.1 done Lukas, could you please verify this ? Thanks in advance. seems to be fixed. Tested with nb trunk 060402 + mobility 060403 on linux machine. I'll mark it verified later when I'll test it on windows. *** Issue 74652 has been marked as a duplicate of this issue. *** verified in release55 branch *** Issue 77682 has been marked as a duplicate of this issue. *** *** Issue 79309 has been marked as a duplicate of this issue. *** *** Issue 82962 has been marked as a duplicate of this issue. *** *** Issue 83172 has been marked as a duplicate of this issue. *** *** Issue 89128 has been marked as a duplicate of this issue. *** *** Issue 95498 has been marked as a duplicate of this issue. *** *** Issue 103953 has been marked as a duplicate of this issue. *** |