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.
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.
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?
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.
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.
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.
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.
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 ------------------------------------------
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.
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)
The URL above points to proposal to change the storage of primitive data types to attributes. I will mention it also on nbdev.
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
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.
verified - closed (projects are dead )