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 22456 - FileObject settings de-serialize into the SystemFileSystem
Summary: FileObject settings de-serialize into the SystemFileSystem
Status: CLOSED WORKSFORME
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P3 blocker (vote)
Assignee: Jan Pokorsky
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-15 20:42 UTC by Rich Unger
Modified: 2008-12-22 18:50 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Unger 2002-04-15 20:42:42 UTC
When saving FileObjects as project settings (and system 
settings, maybe?) and restarting netbeans, the FileObject 
gets de-serialzed and placed in the SystemFileSystem, no 
matter where it originated.

The problem shows up when overriding SystemOption like 
this:

    public void writeExternal( ObjectOutput out )
        throws IOException
    {
        super.writeExternal(out);
        out.writeObject(getMyFileObject());
    }

    public void readExternal( ObjectInput in )
        throws IOException, ClassNotFoundException
    {
        super.readExternal(in);
        FileObjectWrapper fo = (FileObject)in.readObject();
        setMyFileObject(fo);
    }

I can work around the bug by changing this code to:

    public void writeExternal( ObjectOutput out )
        throws IOException
    {
        super.writeExternal(out);
        out.writeObject(new FileObjectWrapper
(getMyFileObject()));
    }

    public void readExternal( ObjectInput in )
        throws IOException, ClassNotFoundException
    {
        super.readExternal(in);
        FileObjectWrapper foWrapper = (FileObjectWrapper)
in.readObject();
        setMyFileObject(foWrapper.getFileObject());
    }
    
    protected static class FileObjectWrapper implements 
Serializable
    {
        FileObjectWrapper( FileObject fo )
        {
            m_sPath = fo.toString();
            try
            {
                m_fileSystem = fo.getFileSystem();
            }
            catch( FileStateInvalidException ex )
            {
                ex.printStackTrace();
            }
        }

        FileObject getFileObject()
        {
            if( m_fileSystem == null )
            {
                return null;
            }
            return m_fileSystem.findResource(m_sPath);
        }

        private String m_sPath;
        private FileSystem m_fileSystem;
    }
Comment 1 Jan Pokorsky 2002-04-16 14:12:39 UTC
Is the filesystem which the fileobject belogs to mounted in the 
Repository when you store the fileobject (setting)?

If the filesystem is stored as a project part (it is the most often 
case and you can verify it in Tools->Options window) then your 
SystemOption has to be a project part too (this should be the root of 
evils).

Your workaround is not correct. You serialize all the filesystem not 
just handle to it. So after deserialization new filesystem is created 
instead of using the one from the Repository.

See also org.openide.filesystem.AbstractFileObject.writeRaplace
Comment 2 Rich Unger 2002-04-27 21:06:34 UTC
I've fixed all that, and I'm still seeing the problem.  
I'm no longer overriding readExternal/writeExternal.  My 
FileObject project setting is being de-serialized into the 
SystemFileSystem.

Could it be a race condition?  If the reading of this 
project setting beats the reading of the filesystems in 
the repository, will it back off to the SystemFileSystem?

I'll try and track it down further.
Comment 3 Jan Pokorsky 2002-05-01 21:59:56 UTC
Maybe if you read the setting in your ModuleInstall subclass and your 
module is turned on before projects module it would be possible. 
Otherwise it has to work. Files in your editor are opened properly 
after startup, are not they? Try to add some logs to 
readExternal/writeExternal and check the filesystem is in the 
Repository.
Comment 4 Jan Pokorsky 2002-05-21 13:18:28 UTC
Any progress?
Comment 5 Jan Pokorsky 2002-06-05 14:49:25 UTC
Without some test case or more details I'm not able to evaluate what's 
wrong. I have to close it as works for me.
Comment 6 Rich Unger 2002-06-05 18:37:14 UTC
We've been trying to reproduce this consistently, but 
haven't been able to.  We haven't been able to reproduce 
it at all in the 3.4 branch.  I'm fine with closing this.
Comment 7 Quality Engineering 2003-07-01 15:55:42 UTC
Resolved for 3.4.x or earlier, no new info since then -> verified
Comment 8 Quality Engineering 2003-07-01 16:16:17 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.