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 34551 - Context impl over FS does not merge primitive data types
Summary: Context impl over FS does not merge primitive data types
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P1 blocker (vote)
Assignee: David Konecny
URL: http://openide.netbeans.org/proposals...
Keywords:
Depends on:
Blocks:
 
Reported: 2003-06-24 11:36 UTC by David Konecny
Modified: 2008-12-22 20:40 UTC (History)
4 users (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 David Konecny 2003-06-24 11:36:20 UTC
Context implementation over FS does not merge
primitive data types if underlaying filesystem is
MultiFilesystem. The MFS merges only files and
attributes. That means that only one
settings.properties file is visible. All others
from lower layers are ignored.

Current implementation correctly solves this only
for SystemFS - it works directly with the
SessionManager and its two filesystems and merge
the settings.properties file from
SessionManager.LAYER_INSTALL and
SessionManager.LAYER_SESSION.

New projects uses their own impl of multiFS for
which this does not work and it is serious problem
for them and they need some short term solution
immediatelly.

Possible solutions are:

Short term solution:
1.) change the format of primitive bindings so
that each primitive binding is one file. MultiFS
would then take care about everything.
2.) change Context impl to be aware of MultiFS and
its layers. That would allow the implementation to
do the merge.

Long term solution is:
- Context over FS impl works with plain FS only
(no special support for multiFS)
- MergedContext with contexts for each FS layer is
used instead of one context over the multiFS. That
allow MergedContext to properly merge the
primitive bindings. (The proper working of this
depends on the Convertors API. Without Convertors
API is InstanceDO comming from one of merged
contexts stored due to *autosaving* feature to the
same context from which it comes. The expected
behaviour is that object would be stored into
writable layer of merged context.)

At the moment I tend to implement short term
solution #2. 

There still remain one issue related to
MultiFS.createWritableOn(). It is used in new
projects for storing settings into diff writable
layers - shared writable layer and local writable
layer. I will comment this later.
Comment 1 David Konecny 2003-06-24 12:46:40 UTC
MultiFS.createWritableOn() issue:

The long term solution is:
Implement your own IntelligentContext which delegates read and write
operations according to its logic to two other writable contexts -
shared data context and local data context (from impl point of view
these two can be FS contexts). Create MergedContext where writable
layer is IntelligentContext and readonly layers are whatever other
context you need.

The short term solution:
Similar to long term solution, but a bit messier. Create
IntelligentContext which again delegates to two contexts: first one is
context created for projectFS (let say that data written to this
context end up in "shared data" layer); second context is created for
"local data" layer. This second layer is already subset of the first
one (needed because some code can access directly the projectFS) and
this is the only bigger difference to the long term solution which
must be solved in IntelligentContext. e.g. writting something to
second context results in events from first context which must be
ignored, etc.

This is how I see it at the moment. Any better suggestions?
Comment 2 Jesse Glick 2003-06-24 20:27:58 UTC
Your analysis sounds right to me. The proper long-term solution IMHO
is that all merging is done at the Registry level, using some merging
RootContext impl. (Radek is already working on this, right?)

If there is code in Projects using the FS level directly, that code
should be replaced sooner or later. I will assume it is too big and
complicated to change right away. If we need to put in some short-term
hacks to make it work, then OK, so long as it does not pollute the API
for eventual fixing.
Comment 3 Vitezslav Stejskal 2003-06-25 10:22:50 UTC
This is just a sidenote, but I think it's worth to say. In projects
there are still many situations when access to FileObjects is far more
efficient (or even the only way) than using Registry API. That's why I
doubt we will be able to disallow access to ProjectFileSystem in the
future. The bad thing is that we will have to duplicate logic
controlling the target layer for writing files in both
InteligentContext and ProjectFileSystem. Moreover the implementation
of InteligentContext will probably have to depend on (or workaround)
some implementation details of MultiFileSystem because it will touch
its internals - the layers.

Q: Have you considered storing bindings of primitive type as
attributes of their parent context?

That would leverage behavior of MultiFileSystem which already does
merge attributes on folders accros the layers. 
Comment 4 David Konecny 2003-06-25 15:36:43 UTC
Fixed in:

Checking in
openide/registry/test/unit/src/org/netbeans/api/registry/EventsTest.java;
new revision: 1.5; previous revision: 1.4
Checking in core/registry/manifest.mf;
new revision: 1.5; previous revision: 1.4
Checking in
core/registry/src/org/netbeans/api/registry/fs/FileSystemContextFactory.java;
new revision: 1.2; previous revision: 1.1
Checking in core/registry/src/org/netbeans/core/registry/ContextImpl.java;
new revision: 1.9; previous revision: 1.8
Checking in
core/registry/src/org/netbeans/core/registry/PrimitiveBindings.java;
new revision: 1.5; previous revision: 1.4
Checking in
core/registry/src/org/netbeans/core/registry/RootContextImpl.java;
new revision: 1.3; previous revision: 1.2
Checking in
core/registry/src/org/netbeans/core/registry/olddsimpl/DSListener.java;
new revision: 1.2; previous revision: 1.1
Checking in core/registry/test/.cvsignore;
initial revision: 1.1
Checking in core/registry/test/build.xml;
initial revision: 1.1
Checking in core/registry/test/cfg-unit.xml;
initial revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/api/registry/fs/FileSystemContextFactoryTest.java;
initial revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/api/registry/fs/data/fs1.xml;
initial revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/api/registry/fs/data/fs2.xml;
initial revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/api/registry/fs/data/s1.properties;
initial revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/api/registry/fs/data/s2.properties;
initial revision: 1.1

More comments will follow.
Comment 5 David Konecny 2003-06-25 15:55:02 UTC
Jesse: yes, I agree with this proper long term solution. And yes Radek
is working on merged context.

Vita: yes, I considered it. I would use attributes if it would be
implementation detail. But it is not implementation detail - the
format must be documented and will be used for declarative definition
of the defaults. And because of this I found attributes inadequate.

Dusan: in the commit above I added new API method 
FileSystemContextFactory.setDelegates(RootContext,FileSystem[]);
which should solve this issue. Please check its JavaDoc, try it and
let me know if you have some questions.
Comment 6 Vitezslav Stejskal 2003-06-25 16:13:29 UTC
Ehm, I had to miss something, but could you elaborate a bit more why
is using attributes (#1) less adequate than properties files (#2)?
Just by comparing the complexity I would prefer #1.

- 1 -----------------------------------------

<folder name="myCtx">
    <attr name="primitiveBinding" stringvalue="ahoj"/>
</folder>

- 2 -----------------------------------------

<folder name="myCtx">
    <file name="settings.properties" url="settings.properties"/>
</folder>

settings.properties file:
primitiveBinding=ahoj

------------------------------------------

Comment 7 David Konecny 2003-06-25 16:57:51 UTC
The full example could look like:

<folder name="myCtx">
 <attr name="name" stringvalue="primitive binding"/>
 <attr name="XX:name" stringvalue="context attribute"/>
 <attr name="YY:name" stringvalue="primitive binding attr"/>
</folder>

where XX: and YY: are some prefixes for context attributes and
primitive bindings attributes. This is what I meant. I do not like
that much. Also "<attr>" tag used for primitive bindings is kind of
strange. I'm not saying that current solution with properties file is
great, but IMO is a bit better than attributes.

Anyway, in the long term I do not think we want to stick to MultiFS.
Implementing writable implementation of BasicContext for the XML file
with structure like eg. this:

<root>

  <context name="ctx1">

    <attr name="name" value="context attr"/>

    <object name="compiler">

        <!-- some embedded xml with separate Convertor -->
        <instance class="..." method="...">
          <param name="..." value="..."/>
        </instance>

    </object>

    <primitive name="..." stringvalue="primitive binding"/>

  </context>

</root>

should be pretty easy. The MergedContext will allow us to merge
contexts like these. And that's our goal I think - to be able to
evolve current format. From this point of view I see multiFS (and its
features) playing less important role in future.
Comment 8 Vitezslav Stejskal 2003-09-02 17:06:31 UTC
Well, sorry for really late response to this issue, but hallway
discussions don't seem to help. Please, note that I've added the
projects word to the status whiteboard in order to mark this as an
OFFICIAL REQUIREMENT from projects team.

I understand that you have some visions about the future of registry
API, replacing SystemFileSystem and maintaining settings at all.
That's nice and I am your big fan. What I really do not understand is
why you still reject to make the current implementation of
core/registry module to work correctly over the MultiFileSystem when
the way how people will register bindings will change anyway (even
your the settings.properties files will not be used in the furture).

I really do not understand why you don't want to reuse the code of
MultiFileSystem in the registry backend and are trying to implement it
yourself through some fancy MergeContexts or so. There are clear
advantages of using MFS:

- it's maintained for couple of years (lot's bugfixes has been made)
- it's covered by filesystem tests and its functionality is proofed in
the field
- people are familiar with it (everybody is able to write XML layers
and understands their merging)
Comment 9 David Konecny 2003-09-08 13:23:39 UTC
The URL above points to proposal to change the storage of primitive
data types to attributes. I will mention it also on nbdev.
Comment 10 David Konecny 2003-09-11 15:37:26 UTC
Implemented according to proposal. What remains to do is to document
the format of primitive data bindings in the API of core/registry
module. Till it is done please consult the proposal if something is
not clear. The implementation is done exactly as it is described in
proposal.

Implemented in:
Checking in openide/registry/test/cfg-unit.xml;
new revision: 1.3; previous revision: 1.2
Checking in
openide/registry/test/unit/src/org/netbeans/api/registry/AttributeTest.java;
new revision: 1.5; previous revision: 1.4
Checking in
openide/registry/test/unit/src/org/netbeans/api/registry/BindingTest.java;
new revision: 1.7; previous revision: 1.6
Removing
openide/registry/test/unit/src/org/netbeans/api/registry/ResettableTest.java;
new revision: delete; previous revision: 1.2
Checking in core/registry/build.xml;
new revision: 1.9; previous revision: 1.8
Checking in core/registry/manifest.mf;
new revision: 1.6; previous revision: 1.5
Checking in core/registry/api/apichanges.xml;
initial revision: 1.1
Checking in core/registry/api/doc/overview.html;
initial revision: 1.1
Checking in
core/registry/src/org/netbeans/api/registry/fs/FileSystemContextFactory.java;
new revision: 1.3; previous revision: 1.2
Checking in core/registry/src/org/netbeans/core/registry/ContextImpl.java;
new revision: 1.12; previous revision: 1.11
Checking in core/registry/src/org/netbeans/core/registry/Listener.java;
new revision: 1.4; previous revision: 1.3
Removing
core/registry/src/org/netbeans/core/registry/PrimitiveBindings.java;
new revision: delete; previous revision: 1.5
Checking in
core/registry/src/org/netbeans/core/registry/ResettableContextImpl.java;
new revision: 1.2; previous revision: 1.1
Checking in
core/registry/src/org/netbeans/core/registry/ResettableRootContextImpl.java;
new revision: 1.3; previous revision: 1.2
Checking in
core/registry/src/org/netbeans/core/registry/RootContextImpl.java;
new revision: 1.4; previous revision: 1.3
Checking in
core/registry/src/org/netbeans/core/registry/olddsimpl/ObjectBindings.java;
new revision: 1.3; previous revision: 1.2
Checking in
core/registry/test/unit/src/org/netbeans/api/registry/fs/FileSystemContextFactoryTest.java;
new revision: 1.3; previous revision: 1.2
Removing
core/registry/test/unit/src/org/netbeans/api/registry/fs/OrderingTest.java;
new revision: delete; previous revision: 1.1
Removing
core/registry/test/unit/src/org/netbeans/api/registry/fs/data/fs1.xml;
new revision: delete; previous revision: 1.1
Removing
core/registry/test/unit/src/org/netbeans/api/registry/fs/data/fs2.xml;
new revision: delete; previous revision: 1.1
Removing
core/registry/test/unit/src/org/netbeans/api/registry/fs/data/layer1.xml;
new revision: delete; previous revision: 1.1
Removing
core/registry/test/unit/src/org/netbeans/api/registry/fs/data/layer2.xml;
new revision: delete; previous revision: 1.1
Removing
core/registry/test/unit/src/org/netbeans/api/registry/fs/data/s1.properties;
new revision: delete; previous revision: 1.1
Removing
core/registry/test/unit/src/org/netbeans/api/registry/fs/data/s2.properties;
new revision: delete; previous revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/core/registry/BindingTest.java;
initial revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/core/registry/OrderingTest.java;
initial revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/core/registry/ResettableTest.java;
initial revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/core/registry/TestMFS.java;
initial revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/core/registry/data/layer1.xml;
initial revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/core/registry/data/layer2.xml;
initial revision: 1.1
Checking in
core/registry/test/unit/src/org/netbeans/core/registry/data/layer_defaults.xml;
initial revision: 1.1
Comment 11 David Konecny 2003-10-08 15:53:19 UTC
I had to prefix also attributes on primitive bindings. It was
necessary to distinguish context attribute from primitive binding
attribute. I found out that previous solution did not work in some
cases and so I just added explicit prefix "BINDINGATTR:" for primitive
bindings attribute. The syntax really is getting pretty ugly.
Hopefully we will replace it soon. And hopefully attributes on
primitive bindings will not be used often (if ever) so clients should
not be bothered by this syntax too much. 

Update of core/settings Javadoc with details about declarative format
is still pending.
Comment 12 Marian Mirilovic 2004-02-24 07:51:53 UTC
verified - closed (projects are dead )