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.
If you create a tag library, add tags to it, generate tag handlers and a .jar, the tags will not be properly added to the .jar The .tld isn't being saved when the tags are added. This would make for a P1 bug, however there's an easy workaround which is to have the .tld open in the source editor when you add the tags. In this case, the IDE will know that it has unapplied changes and will save the changes.
The workaround isn't particularly easy to find, raising to P1.
When the tld document is not open in the editor, the TLD data object saves the tld with every change. At least, it's supposed to. This appears not to be working in certain cases.
This bug seems to be a timing glitch, since it is intermittent, and the presence or absence of debug statements affects the outcome. Here's why I think the bug is happening: When a new tag is added, it is created already attached to a taglib (requirement ofthe constructor). Then a customizer dialog is brought up and the user can edit the fields, and then decide whether to actually add the tag or not. If OK, then the tag is added to the tag library. When changes are made to a tag, the tag's dirty bit is set, and propagated to its taglib, which kicks off the regenerate document routine that results in it getting saved. What was happening was that the changes made to the tag before it was added to the taglib were getting propagated anyways, and the taglib was writing itself to the document (and saving) when it wasn't really necessary. Why is this so bad? Well, recently, an optimization was introduced where if a regeneration task is in progress, a new one is not kicked off. So here is where the timing error came in: the taglib was writing itself because of changes made to the new tag, but the new tag wasn't added yet, so didn't get written. When the new tag got added, sometimes the taglib had finished writing itself, and so would writeitself again, this time with the new tag. But sometimes the taglib hadn't finished writing iteself, and the write-with-new-tag task doesn't get run. Two solutions: long range, fix the optimization so that if a new regen task comes in, the new one wins. short term, fix the tag's dirty bit mechanism so it doesn't propagate to the taglib when it isn't added to the taglib. Status: I have a fix, and am waiting for approval to integrate. Simran
integration approved
verified on Orion trunk build 2002-03-27
Changing target milestone to FFJ 4.0
This bug is being reopened because it reappears in FFJ4.0 RC2 (and RC1). Due to the intermittent nature of the bug I'm inclined to say that it has existed all along, that the earlier fix simply reduced its frequency.
This one has been fixed in Orion RC4. Here is the analysis that went with the code review: It's basically a problem with two-way editing. This fix also fixes the cut/paste P1 bug we had been seeing, but which we feel didn't pass the code review. It turned out that I found problems with that fix (so it's good that we didn't pass it), and they are fixed here as well. Peter Carlson has done a lot of work testing my fix, reports that the fix works well. The problem is that when multiple changes were made to the data structure, from the explorer or customizers, they would each start threads that would write the data structure out to the document. Then when the document was written out, a property change event was fired on the document which caused it to be parsed, and the changes were merged into the data structure. There were two race conditions present here: A. One change would cause the document to get written, which would cause the document to get parsed, which would set the data structure. Then the second change would cause the document to get written and thus parsed, and set the data structure. If those two were interleaved, then they could have different data in them (often we would see the first change happen, then the second happen, then the first change gets put back when its parse happened). The solution to this race condition was to realize that the change to the document is happening because of a change to the data structure, and in that case we don't need to reparse the document. This was the fix for the cut/paste bug. B. If multiple changes are causing the document to be written more than once, some of the changes were being dropped. This was because I was keeping a single regeneration task, and if a regeneration task was running when a new change came in, then the new change was not causing the document to get written. This is why the added tag was not making it into the document -- first the changes to the new tag were causing a document write to happen, and then the tag getting placed in the tag library were causing another write to happen. If the write from the first change happened too soon, the second change would get lost. If it happened later, then the added tag will be lost. The solution to this is to change the way that the regeneration task is handled. Previously, we would run the task, then null it out to allow for the next one. What we really need to do is to null out the variable before we start the run, so that if another change comes in while one is running, the new one will be queued up. Then, we need to synchronize the run() method (on a data member on the data object) so that successive writes of the document do not interfere with each other.
Simran, will you move the fix into trunk too?
Verified Fixed with FFJ 4.0 FCS
Resolved for 3.4.x or earlier, no new info since then -> closing.