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.
Steps to reproduce: 1. Get fresh FFJ3.0 version 2. On autoupdate center for local/intest intest get XML and Java modules from Sustaining directory 3. Install them, IDE restarts 4. Now the XML bugs does not work (in this case for example Bug #4493221) 5. Restart IDE 6. XML bugs do work now. Looks like the class loader from some reason uses old classes after first restart.
Please try to narrow this down to a smaller testcase if possible, with dummy test modules. I cannot access the "local sustaining directory" you refer to (sorry) and anything involving downloading huge files will make it take much longer for me to even start investigating this...
Created attachment 2596 [details] log file from ide running with -J-Dorg.netbeans.core.modules=0 -J-Dnetbeans.debug.exceptions=true switches
The ide.log I attached exactly follows steps 1-4 from the reproduction process described in this bug by J.Kovar.
Jesse, what you can do is to use just java and XML nbm files and you can use local versions of them stored at Transfer\anebuzelsky\JP3.1- Merlin directory. Also here is the quickest way how to see whether the update works fine: 1. Get Java and XML nbm installed 2. Create new XML file 3. on the root element do right-click and choose new-attribute 4. fill any name and click on value, if an exception is thrown the version of the class (org.netbeans.modules.xml.tree.beans.customizer.TreeAttributeCustomize r) stored in userdir is not used. 5. restart the IDE 6. the fix work properly
Martin writes: ------%<------ this is an excerpt from ide.log I attached to #15599 with the switches you suggested. This part looks 'buggy' to me. [org.netbeans.core.modules] Module already exists org.netbeans.modules.xml: existing.base=1 existing.release=1 existing.spec=1.5.0.1 mi.base=2 mi.release=1 mi.spec=1.5 [org.netbeans.core.modules] Older than existing module, ignoring... ------%<------ I think this is fine, that means the homedir xml.jar is consider older than the "existing" userdir xml.jar--don't be scared of strange release32 module installer messages, they don't make any sense to me either, because nobody really understands how it works. I will try to get the NBMs mentioned and test against 3.0 FCS EE as of Aug 17, which I have a copy of lying around.
Jesse, I'll send you the nbms, they are quite big to attach them here. Or you can find them on my workstation: honza-sun.czech location: /export/share/ Test them against FFJ3.0 (build from 010817). Thanks.
Created attachment 2607 [details] Suggested patch
I was able to reproduce, thank you for the detailed instructions... Seems to happen when: more than one module is updated simultaneously; and among the modules after the first, at least one is used as a dependency by some other enabled module; and then with 50% probability per updated module. I am attaching a patch to 3.2.1 sources which I believe fixes the problem. I have *not* committed it to CVS. Naturally this should be taken with extreme caution; any change to the module system (especally in 3.2) has the potential to introduce other more serious bugs, and should be tested well before using. It is very unlikely this bug would be present in 3.3 as the module system is completely rewritten and the system of upgrades is handled quite differently. Note that the line "[AutoUpdate] warning: no license found with name" printed on the console probably means someone screwed up making the NBM file.
*** Issue 15648 has been marked as a duplicate of this issue. ***
This and the duplicated issue seems fine now. I'll verify them when the new version of JP will be avaible.
verified in Nb 200209250100 This old bug. We have now ffj4.0 version
Resolved for 3.4.x or earlier, no new info since then -> closing.