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 23609 - Module layers are not ordered properly
Summary: Module layers are not ordered properly
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Jesse Glick
: 27394 (view as bug list)
Depends on: 21153 21173
  Show dependency tree
Reported: 2002-05-16 14:56 UTC by mslama
Modified: 2008-12-22 18:39 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

our module (157.51 KB, application/octet-stream)
2002-05-16 14:58 UTC, mslama
Module welcome with dependency on core-ui (177.34 KB, application/octet-stream)
2002-05-20 10:31 UTC, mslama
Diff for (1.25 KB, patch)
2002-05-20 10:36 UTC, mslama
Details | Diff
Log of failed unit test incl. extra debug info re. contents of XMLFileSystem (85.99 KB, text/plain)
2002-05-24 19:35 UTC, Jesse Glick
ide.log (340.07 KB, text/plain)
2002-06-20 17:31 UTC, mslama
cache/all-layers.xml (367.43 KB, text/plain)
2002-06-20 17:32 UTC, mslama

Note You need to log in before you can comment on or make changes to this bug.
Description mslama 2002-05-16 14:56:40 UTC
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.
Comment 1 mslama 2002-05-16 14:58:39 UTC
Created attachment 5776 [details]
our module
Comment 2 mslama 2002-05-16 15:00:44 UTC
I just put welcome.jar to modules folder and start IDE with empty user
dir. I checked source using URLMapper from winsys parser.

Comment 3 _ ttran 2002-05-16 15:05:00 UTC
Isn't this bug related to caching xml layer?  I recall Yarda talking
about caching layers loses ordering info
Comment 4 rmatous 2002-05-17 14:47:13 UTC
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. ...). 
Comment 5 Jesse Glick 2002-05-17 20:35:46 UTC
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
Comment 6 mslama 2002-05-17 21:04:52 UTC
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.

Comment 7 Jesse Glick 2002-05-17 21:20:11 UTC
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);

And yes, please depend on core/ui, not core.
Comment 8 Petr Nejedly 2002-05-20 08:02:06 UTC
> If I understand it correctly welcome.jar should be BEFORE core.jar
> if welcome depends on core. Right?
If A depends on B, A will be after B.
Jesse, you have STARTed it, will you close it as invalid again?
Comment 9 mslama 2002-05-20 08:51:36 UTC
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?
Comment 10 Petr Nejedly 2002-05-20 09:42:13 UTC
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.
Comment 11 mslama 2002-05-20 10:31:57 UTC
Created attachment 5849 [details]
Module welcome with dependency on core-ui
Comment 12 mslama 2002-05-20 10:34:57 UTC
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

I will attach diff for to log URL for editor.wsmode.
Comment 13 mslama 2002-05-20 10:36:36 UTC
Created attachment 5850 [details]
Diff for
Comment 14 rmatous 2002-05-20 13:38:36 UTC
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.
Comment 15 Jesse Glick 2002-05-20 16:40:07 UTC
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?
Comment 16 rmatous 2002-05-20 16:59:24 UTC
Agreed. #23595 wil be  tomorrow reopened, fix reverted and unit test
Comment 17 Jaroslav Tulach 2002-05-21 12:30:33 UTC
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.
Comment 18 Jaroslav Tulach 2002-05-21 12:59:32 UTC
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...
Comment 19 rmatous 2002-05-21 13:24:26 UTC
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
Comment 20 Jesse Glick 2002-05-21 19:11:22 UTC
Yes, Yarda's 1 & 2 combined are precisely the desired specified
behavior of masking, which #21173 ought to test.
Comment 21 Jesse Glick 2002-05-24 19:34:08 UTC
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.
Comment 22 Jesse Glick 2002-05-24 19:35:37 UTC
Created attachment 5959 [details]
Log of failed unit test incl. extra debug info re. contents of XMLFileSystem
Comment 23 Jesse Glick 2002-05-24 19:37:11 UTC
Compare in the attached log this, from the #1 test:

foo/file3.txt: <customized contents>

to this, from the #2 test:

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.
Comment 24 mslama 2002-06-04 13:12:06 UTC
Current situation is that editor.wsmode is sometimes loaded from
core-ui module sometimes from welcome module. Nondeterministic behaviour.
Comment 25 rmatous 2002-06-04 13:38:45 UTC
Thanks Jesse for investigation. Will be solved.
Comment 26 Jesse Glick 2002-06-18 15:50:34 UTC
Don't forget to patch core/test/cfg-unit.xml if necessary to include
tests in the passing config....
Comment 27 rmatous 2002-06-18 16:34:42 UTC
Fixed in trunk. testDependencyLayerOverrides doesn`t fail anymore,
then cfg-unit.xml was modified.
Comment 28 mslama 2002-06-20 13:34:22 UTC
It does not work correctly. Sometimes we read from core-ui sometimes
from welcome module.
Comment 29 rmatous 2002-06-20 14:21:15 UTC
Investigated. setXmlUrls gets array of urls. There is used caching,
and cache/all-layers.xml contains sometimes record <file
and sometimes <file name="editor.wsmode"
If I switched off caching (new ModuleLayeredFS (,null)) then sometimes
layers are ordered:
sometimes conversely.

reasigned to Jesse
Comment 30 Jesse Glick 2002-06-20 14:34:27 UTC
I will assume that layer ordering is fine, because of issue #24991
which would explain the observed problems.
Comment 31 mslama 2002-06-20 17:25:47 UTC
I still have problem.
Comment 32 mslama 2002-06-20 17:29:10 UTC
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.
Comment 33 mslama 2002-06-20 17:31:16 UTC
Created attachment 6356 [details]
Comment 34 mslama 2002-06-20 17:32:05 UTC
Created attachment 6357 [details]
Comment 35 mslama 2002-06-20 17:37:48 UTC
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.
Comment 36 Jesse Glick 2002-06-20 19:04:59 UTC
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
Comment 37 Jesse Glick 2002-06-21 16:21:29 UTC
Hopefully fixed now for the case that the layer cache manager is
enabled, please check on welcome module.

committed   * Up-To-Date  1.2        
committed   * Up-To-Date  1.2        
Comment 38 mslama 2002-09-25 18:01:13 UTC
*** Issue 27394 has been marked as a duplicate of this issue. ***
Comment 39 Marian Mirilovic 2005-07-12 09:04:09 UTC