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.
a module containing a mimetype based loader doesn't get activated (doesn't recoginize the files with specified extension) when installed into running ide. one needs to restart the IDE in order to get the module/loader working. attaching a sample module.
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.