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 21555 - Prototype of the custom format of settings
Summary: Prototype of the custom format of settings
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Options&Settings (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jan Pokorsky
URL: http://openide.netbeans.org/proposals...
Keywords:
Depends on:
Blocks: 17924
  Show dependency tree
 
Reported: 2002-03-13 13:32 UTC by Jan Pokorsky
Modified: 2008-12-23 13:39 UTC (History)
0 users

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Pokorsky 2002-03-13 13:32:10 UTC
The goal of this task is to implement main ideas mentioned in settings proposals and verify them.
Comment 1 Jan Zajicek 2002-04-05 15:54:40 UTC
Ok and the status of this MILESTONE_2 task is? ;-)
Comment 2 Jan Pokorsky 2002-04-05 16:08:05 UTC
I'm about to check the prototype in cvs asap.
Comment 3 Jan Pokorsky 2002-04-09 02:27:53 UTC
Checked in the settings34_prototype branch.

You should check out:
modules core/settings (infrastructure), core/settings/examples
and some files under module core and openide

Prototype demonstrates usage of convertors with new xml/properties 
format and also old session settings format.
Comment 4 Jaroslav Tulach 2002-04-15 09:54:37 UTC
Hi Jan. I check the settings module and find out that there is no
API/SPI package, that is why I expected that most of the code there is
supposed to be API.

1. I would be glad if there was a way not to expose DataObjects in the
API - replace them with plain InputStream or Lookup or etc...

2. The Settings/Memory/java-lang-Object should have deeper hierarchy
otherwise the XMLFS will have performance problems. I suggest to use
Settings/Memory/java/lang/Object.settings

3. For ease of upgrades of modules it is desirable not to store names
of classes with data (if possible). That is why storing attribute
instanceClass="..." with all properties is not good thing to do. I
believe that own DTD would work better.