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.
We have module that defined in winsys folder file editor.wsmode to overwrite the same file in module core-ui. The problem is that file from core-ui is loaded instead of from our module welcome.jar.
Created attachment 5776 [details] our module
I just put welcome.jar to modules folder and start IDE with empty user dir. I checked source using URLMapper from winsys parser.
Isn't this bug related to caching xml layer? I recall Yarda talking about caching layers loses ordering info
Jesse, please evaluate. XMLFileSystem.setXMLUrls obtains URL[] and merges them. But layer from welcome module is positioned after core-ui. To be frank I don`t know how should be modules ordered (except dependencies). I know that modules with well defined extensions are placed at the top (branding, localiz. ...).
If A and B both define the same file in their layer, and neither A nor B has a direct nor indirect dependency on the other, it is arbitrary which version will be used. You must use module dependencies to guarantee a particular ordering. If A depends on B, A can override a file in B's layer. BTW in your welcome.jar manifest: - OpenIDE-Module-Name should not be there, use the loc'g bundle instead - Class-Path is bogus - the OpenIDE-Module code name is technically legal but it is conventional to use a package name, e.g. org.netbeans.modules.welcome, rather than a class name as you do
welcome module depends on core.jar and still welcome.jar is not before core.jar. As Jarda suggested I listed urls in ModuleLayeredFileSystem.setURLs and welcome.jar is last in list. If I understand it correctly welcome.jar should be BEFORE core.jar if welcome depends on core. Right? Or is there other place where to check order of layers? Richard please add dependency on core-ui.jar instead of core.jar and I will check it again.
I don't know offhand if XMLFileSystem.setXmlUrls assumes that the *earlier* layers take precedence, or the *later* ones. It is not documented in XMLFileSystem and I don't remember. Maybe Radek will know. NbInstaller seems to assume that the later ones will be able to override the earlier ones. Perhaps it is backwards. I will try to check it by writing a test for #21173. In parallel, you can try adding to NbInstaller.loadLayers, after the first line (ev.log(...)): modules = new ArrayList(modules); Collections.reverse(modules); And yes, please depend on core/ui, not core.
> If I understand it correctly welcome.jar should be BEFORE core.jar > if welcome depends on core. Right? NO! If A depends on B, A will be after B. Jesse, you have STARTed it, will you close it as invalid again?
If it is as Petr said is there any way how we can overwrite file in layer of module core-ui by file in layer of module welcome?
Let the welcome module depend on the core-ui. The welcome module layer will be after the core-ui layer and will override core-ui's files.
Created attachment 5849 [details] Module welcome with dependency on core-ui
I tested new welcome module with dependency on core-ui but result is the same. I also did change in NbInstaller.loadLayers but no effect. I use URLMapper.findURL and it gives: ModeData.readData fo:editor url:jar:file:/mnt/local/mslama/netbeans/netbeans_test/lib/core-ui.jar!/org/netbeans/core/ui/resources/windowmanager/Editing/editor.wsmode I will attach diff for ModeData.java to log URL for editor.wsmode.
Created attachment 5850 [details] Diff for ModeData.java
As Jesse pointed out, XMLFileSystem.setXMLUrls doesn`t document precedence. I ran into this problem also a few days ago #23595, that I solved it in such way, that I changed precedence, because NbInstaller places branded and localized layers before other layeres (lower indexes in array). So, layeres with lower indexes in array take precedence at the moment. Or I can revert this change, but there must be agreement, then will be right implemented and documented.
I would suggest that the recent patch to XMLFileSystem be reverted, at least whatever changed the precedence order, for possible compatibility with previous releases; and the behavior be documented as well (please test in org.openide.filesystems unit tests). Then I suppose this bug would become fixed, issue #23595 would be reopened, and I would fix #23595 by reversing the order of branded/localized layers sent to XMLFS.setXmlUrls. OK?
Agreed. #23595 wil be tomorrow reopened, fix reverted and unit test written.
I am a bit biased, but there is no doubt that the correct behaviour is that the first wins. So the content of lower URL in setURLs shall mask the higher. Because this has not been documented yet, I vote for documenting this and also cover it with tests so we won't run into this problem again.
To make my previous comment clearer: it was about XML fs. As concern the module layers: 1. the branded layer should take preceedence over the not-branded one 2. if a module A depends on module B then the layer of module A shall take precedence to layer of module B (because A can know what is in layer of B). Is this reasonable assumption? If so, the welcome.jar can depend on core-ui and mask what ever resource is necessary to mask...
So, XMLFileSystem (rev. 1.59) is in agreement with Jarda`s sugestion at the moment. 1. is also OK 2. must be changed probably somwhere in NBInstaller
Yes, Yarda's 1 & 2 combined are precisely the desired specified behavior of masking, which #21173 ought to test.
Partially fixed: according to unit tests, if both modules are loaded together (normal startup sequence), it works. But if the base module is loaded first, then the dependent module, not all overrides work: masks work, but modified contents and attributes do not work. The differing behavior is captured in the unit test: NbInstallerTest.testDependencyLayerOverrides1 which loads both together passes, but ...2 which loads them sequentially is in the excluded failing config for now. Patch core/test/cfg-unit.xml when marking this fixed. I will attach a log from the unit test with some additional debug information. It seems to indicate that XMLFileSystem is at fault here. If you start with no layers (or only core layer), then call setXmlUrls with layers {override, base}, you get the right results. But if you start with no layers (or only core layer), then call it with {base} and query the file contents, then call it again with {override, base} and query the file contents again, you still get the base contents. So perhaps some refresh problem in XMLFileSystem, I don't know. Lowering priority since the common case should now be fixed; it is the less common case which is still broken.
Created attachment 5959 [details] Log of failed unit test incl. extra debug info re. contents of XMLFileSystem
Compare in the attached log this, from the #1 test: fs: [jar:file:/space/src/nb_all/core/test/unit/src/org/netbeans/core/modules/jars/override-layer-mod.jar!/overridelayer/layer.xml, jar:file:/space/src/nb_all/core/test/unit/src/org/netbeans/core/modules/jars/base-layer-mod.jar!/baselayer/layer.xml, file:/space/src/nb_all/core/src/org/netbeans/core/resources/mf-layer.xml] foo/file3.txt: <customized contents> to this, from the #2 test: fs: [jar:file:/space/src/nb_all/core/test/unit/src/org/netbeans/core/modules/jars/override-layer-mod.jar!/overridelayer/layer.xml, jar:file:/space/src/nb_all/core/test/unit/src/org/netbeans/core/modules/jars/base-layer-mod.jar!/baselayer/layer.xml, file:/space/src/nb_all/core/src/org/netbeans/core/resources/mf-layer.xml] foo/file3.txt: <base contents> Also, you can delete the debug code from ModuleLayeredFileSystem if you don't need it any longer, it is commented out currently.
Current situation is that editor.wsmode is sometimes loaded from core-ui module sometimes from welcome module. Nondeterministic behaviour.
Thanks Jesse for investigation. Will be solved.
Don't forget to patch core/test/cfg-unit.xml if necessary to include tests in the passing config....
Fixed in trunk. testDependencyLayerOverrides doesn`t fail anymore, then cfg-unit.xml was modified.
It does not work correctly. Sometimes we read from core-ui sometimes from welcome module.
Investigated. setXmlUrls gets array of urls. There is used caching, and cache/all-layers.xml contains sometimes record <file name="editor.wsmode" url="jar:file:/E:/nb19/lib/core-ui.jar!/org/netbeans/core/ui/resources/windowmanager/Editing/editor.wsmode"> and sometimes <file name="editor.wsmode" url="jar:file:/E:/nb19/modules/welcome.jar!/org/netbeans/modules/welcome/windowmanager/Editing/editor.wsmode">. If I switched off caching (new ModuleLayeredFS (,null)) then sometimes layers are ordered: jar:file:/E:/nb19/lib/core-ui.jar!/org/netbeans/core/ui/resources/layer.xml jar:file:/E:/nb19/modules/welcome.jar!/org/netbeans/modules/welcome/mf-layer.xml sometimes conversely. reasigned to Jesse
I will assume that layer ordering is fine, because of issue #24991 which would explain the observed problems.
I still have problem.
I will attach ide.log when IDE starts with -J-Dorg.netbeans.core.modules=0 -J-Dorg.netbeans.core.projects=0 editor.wsmode still loaded from core-ui.jar.
Created attachment 6356 [details] ide.log
Created attachment 6357 [details] cache/all-layers.xml
Cache might cause that. I started IDE with empty user dir 6times with -J-Dnetbeans.layers.cache=- and it was ok: loaded from welcome.jar.
OK, assuming it is some kind of problem with the cache manager then. I think a list just needs to get reversed. Currently the unit tests check that layer overrides work, but they run with the cache manager disabled.
Hopefully fixed now for the case that the layer cache manager is enabled, please check on welcome module. committed * Up-To-Date 1.2 core/src/org/netbeans/core/projects/cache/LayerCacheManager.java committed * Up-To-Date 1.2 core/src/org/netbeans/core/projects/cache/ParsingLayerCacheManager.java
*** Issue 27394 has been marked as a duplicate of this issue. ***
closed