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 21036 - Get rid of the cache hack in XMLFileSystem
Summary: Get rid of the cache hack in XMLFileSystem
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Jesse Glick
Depends on:
Blocks: 20168
  Show dependency tree
Reported: 2002-03-01 07:25 UTC by Jaroslav Tulach
Modified: 2008-12-22 16:42 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2002-03-01 07:25:49 UTC
The code added to XMLFS as part of cache prototype
should disappear as quickly as possible.
Comment 1 Jaroslav Tulach 2002-03-01 07:33:16 UTC
This will require an API change. Probably support for custom writer. I
suggest to use SAX style methods:

protected void startFolder (String name);
protected void startFile (String name, String url);
protected void writeFile (byte[] ) or char[]?
protected void writeAttribute (String name, String type, String value)
protected void endElement ();

That could be used to format and customize (skip attributes, etc.)
content of XMLFS.
Comment 2 Jaroslav Tulach 2002-03-01 07:35:04 UTC
We can either introduce new class or reuse that already present (and
not very useful) XMLFileSystem.Impl. Anyway the class needs to have
those protected methods and also a way how to start the dump.

Comment 3 Jesse Glick 2002-03-01 10:41:36 UTC
Is this really necessary?? The DTD is public, anyone can just read the
XML files with SAX themselves and process them however they see fit.
The only aspects of XMLFileSystem which are not trivially copyable
parsing jobs are:

- FileSystem behavior, which is not needed here

- loading of attribute values from custom formats, which is not done here

- merging files and folders; needed here but surely not very
complicated, especially since a client may need custom logic to handle
the originating XML file for a file/folder/attr

I would rather just move the relevant code to core than introduce and
maintain a new (potentially messy) API for this.
Comment 4 Jaroslav Tulach 2002-03-01 12:52:18 UTC
Obviously better approach. So guys just remove the code from openide
Comment 5 rmatous 2002-03-01 13:02:22 UTC
So, this issue is assigend to me. Jesse please if you plan to move
code from XMLFS yourself the reassigne appropriately. If not then let
me know and I`ll do it.
Comment 6 Jesse Glick 2002-03-01 13:52:16 UTC
I put it there, I should get rid of it.

Thanks for the patch anyway Petr. :-)
Comment 7 Jesse Glick 2002-03-02 18:33:04 UTC
In progress (have apparently working rewrite). As a side effect, split
cache manager into interface + impl: since the impl is no longer
dependent on a hack in XMLFileSystem, it is possible to remove
knowledge of the storage format from ModuleLayeredFileSystem more easily.

If there is time, we can try implementing a binary storage format.
(MDR's btree looks interesting but also rather complicated and
heavyweight - maybe a simple custom binary format with
RandomAccessFile would serve as well.)

Time permitting, I also hope to write a unit test ensuring that the
cache's merged filesystem has the same contents as XMLFileSystem
would, i.e. that it is accurate.
Comment 8 Jesse Glick 2002-03-04 12:33:49 UTC
committed   * Up-To-Date  1.20       
committed   * Up-To-Date  1.14       
committed   * Up-To-Date  1.27       

added       * Up-To-Date  1.1        
added       * Up-To-Date  1.1        
added       * Up-To-Date  1.1        

XMLFileSystem 1.56
Comment 9 Petr Nejedly 2002-03-04 17:21:24 UTC
The new cache impl. doesn't work for the IDE, because
there are wrong attributes used in the module layers
and the cache manager refuses to create the cache for broken layers
e.g. string_V_alue=project

The original XMLMapAttrs implementation was more forgiving
(ignored case) thus it worked before.
Comment 10 Jesse Glick 2002-03-04 19:24:32 UTC
Which is why I fixed all module layers in standard-with-apisupport
config to use correct case, before committing the new impl. Did you do
a full CVS update? See issue #15482 for more.

IMHO the XMLFileSystem impl is wrong; the former module layers were
not validatable against the published DTD, and should have been rejected.
Comment 11 Petr Nejedly 2002-03-05 08:21:49 UTC
Oops, I didn't :(
Comment 12 Jaroslav Tulach 2003-07-14 15:28:30 UTC
Cache hack is gone.