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: | Adding new MIMEResolver does not refresh existing files | ||
---|---|---|---|
Product: | platform | Reporter: | Milos Kleint <mkleint> |
Component: | Data Systems | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jglick, rmatous |
Priority: | P4 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 61879 | ||
Attachments: | sample module zip |
Description
Milos Kleint
2005-08-08 10:41:59 UTC
Created attachment 23557 [details]
sample module zip
I think this may be a FS API issue, not Loaders API - would need to fire changes in the MIME type of a file. ... Workaround in Loaders API might be to trigger pool refresh after change in Lookup<MIMEResolver>? well, the problem might be somewhere else, consider this scenario: 1. create a new empty file named franta.bubla 2. create a new file type that will recognize the .bubla extension. 3. compile it and install it. 4. the franta.bubla file will turn into the new file type. 5. creating a new file frantuvsynek.bubla with the same extension will not turn into the new filetype but will stay as unrecognized file. 6. after restart of IDE both are already of the correct type. Imho the last comment explains the cause. *** This issue has been marked as a duplicate of 61600 *** Note that there is a real bug that I described in my previous comment, which I in fact saw, but it is probably very low priority: if you had a file franta.bubla displayed in the target app *before* you loaded the version of the module with the MIMEResolver + DataLoader, it will stay a DDO until IDE restart. By contrast, if you don't use MIMEResolver - just use ExtensionList.addExtension in your DL - it works (the existing file is reloaded as your new type). I know that DataLoaderPool changes trigger refreshes of all loaded DataObject's; should we then do the same after a Lookup<MIMEResolver> change? Reopening accordingly. "#61918: Reacting to change of MIMEResolvers and rechecking the state of data objects" Checking in src/org/netbeans/core/LoaderPoolNode.java; /cvs/core/src/org/netbeans/core/LoaderPoolNode.java,v <-- LoaderPoolNode.java new revision: 1.81; previous revision: 1.80 done Checking in startup/src/org/netbeans/core/startup/ManifestSection.java; /cvs/core/startup/src/org/netbeans/core/startup/ManifestSection.java,v <-- ManifestSection.java new revision: 1.3; previous revision: 1.2 done RCS file: /cvs/core/test/unit/src/org/netbeans/core/filesystems/FileEntityResolverTest.java,v done Checking in test/unit/src/org/netbeans/core/filesystems/FileEntityResolverTest.java; /cvs/core/test/unit/src/org/netbeans/core/filesystems/FileEntityResolverTest.java,v <-- FileEntityResolverTest.java initial revision: 1.1 This fix caused a startup regression. See issue 67844. I suggest to revert the fix, if this really is only P4. We need to get rid of the startup regression ASAP. |