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.

Bug 61918 - Adding new MIMEResolver does not refresh existing files
Summary: Adding new MIMEResolver does not refresh existing files
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Data Systems (show other bugs)
Version: 5.x
Hardware: All All
: P4 blocker (vote)
Assignee: Jaroslav Tulach
URL:
Keywords:
Depends on:
Blocks: 61879
  Show dependency tree
 
Reported: 2005-08-08 10:41 UTC by Milos Kleint
Modified: 2008-12-22 16:56 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
sample module zip (8.91 KB, application/x-compressed)
2005-08-08 10:42 UTC, Milos Kleint
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milos Kleint 2005-08-08 10:41:59 UTC
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.
Comment 1 Milos Kleint 2005-08-08 10:42:34 UTC
Created attachment 23557 [details]
sample module zip
Comment 2 Jesse Glick 2005-08-08 17:39:50 UTC
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>?
Comment 3 Milos Kleint 2005-08-09 07:50:43 UTC
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.
Comment 4 Jaroslav Tulach 2005-08-09 08:09:42 UTC
Imho the last comment explains the cause. 

*** This issue has been marked as a duplicate of 61600 ***
Comment 5 Jesse Glick 2005-08-09 17:34:44 UTC
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?
Comment 6 Jesse Glick 2005-08-09 17:35:52 UTC
Reopening accordingly.
Comment 7 Jaroslav Tulach 2005-10-28 10:49:21 UTC
"#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 
 
Comment 8 Antonin Nebuzelsky 2005-11-01 10:20:29 UTC
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.