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: | Install-Before not working after new module introduced. | ||
---|---|---|---|
Product: | platform | Reporter: | Michael Ottati <ottati> |
Component: | Module System | Assignee: | Jesse Glick <jglick> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jtulach, mihmax, ttran |
Priority: | P3 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Windows ME/2000 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 29671 | ||
Bug Blocks: | |||
Attachments: |
Zip file with additional files for this case.
IDE Log with old (pre manifest change) ser file used at startup. IDE Log when loaders.ser was first purged from the userdir Options screen with old loaders.ser file Options screen when loaders.ser has been purged. Possible patch Proposed 3.4.1 patch |
Description
Michael Ottati
2002-10-18 19:17:33 UTC
Created attachment 7709 [details]
Zip file with additional files for this case.
Oops, forgot to have you set -J-Dorg.netbeans.core.LoaderPoolNode=0 during all these operations and attach ide.log. That would be helpful. Created attachment 7710 [details]
IDE Log with old (pre manifest change) ser file used at startup.
Created attachment 7711 [details]
IDE Log when loaders.ser was first purged from the userdir
Well, the log claims that your loader was in fact installed before either of the JAR loaders. Did you confirm that the ordering was actually incorrect in Object Types in the Options dialog, or just that file recognition failed to work as expected until after a restart? If you did not check this, my guess is that the refreshing of the data object pool was the problem, not the loader ordering. Created attachment 7724 [details]
Options screen with old loaders.ser file
Created attachment 7725 [details]
Options screen when loaders.ser has been purged.
I have attached the options screens. Looks to me like the order is different depending on if I start with the old loaders.ser file or if I start with no loaders.ser file. Indeed. Unfortunately the order reported in the log file under "After sort:" does not at all match the order shown in the Object Types node. Looks like readPool() reverted the order. If you *add* a new loader with an Install-Before or Install-After declaration, the pool gets resorted. But I guess adding such an ordering attr to an *existing* loader does not trigger the resort. Please try the attached patch (untested) and let me know if it fixes the problem for you. Created attachment 7726 [details]
Possible patch
See also issue #13880 which was somewhat similar. Seems to be fixed now. committed Up-To-Date 1.62 core/src/org/netbeans/core/LoaderPoolNode.java Created attachment 8112 [details]
Proposed 3.4.1 patch
Someone want to review this patch please? Still awaiting review. Hi. This issue is marked as 3.4.1_CANDIDATE. It means that it should be integrated into release341 one branch. The plan at http://www.netbeans.org/devhome/docs/releases/34/index.html expected beta1 to be produced on Dec01. That did not happen due to a lot of outstanding not integrated candidates like this one. Would it be possible to spend few minutes by backporting this fix? Thank you in advance. How should I review this, I have not seen the class for a long time. I can only confirm that the changes look fine. And if it seems to work then fine. In release341:
Checking in core/src/org/netbeans/core/LoaderPoolNode.java;
/cvs/core/src/org/netbeans/core/LoaderPoolNode.java,v <--
LoaderPoolNode.java
new revision: 1.58.46.1; previous revision: 1.58
done
To verify: confirm that under Object Types, Image is below URL. Shut
down. Edit image.jar manifest:
<<<
Install-Before: org.netbeans.modules.text.TXTDataObject
===
Install-Before: org.netbeans.modules.text.TXTDataObject,
org.netbeans.modules.url.URLDataObject
>>>
Restart. Image should be above URL.
closed |