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 141925 - Reliable layer overrides without artificial module dependencies
Summary: Reliable layer overrides without artificial module dependencies
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
Depends on: 181460 195827
Blocks: 71439 187991 199823
  Show dependency tree
Reported: 2008-07-28 17:50 UTC by Jesse Glick
Modified: 2011-11-01 21:33 UTC (History)
5 users (show)

See Also:
Exception Reporter:

Possible patch (10.10 KB, patch)
2008-07-28 19:28 UTC, Jesse Glick
Details | Diff
Revised patch (41.84 KB, patch)
2010-02-22 15:16 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2008-07-28 17:50:08 UTC
Currently if you wish to override a layer entry with path "folder/data" defined in module m1 with an entry folder/data
defined in m2, then m2 needs to have a dependency on m1 to ensure that it is loaded "after" m1. (In project.xml, this
would be a <run-dependency> with no <build-prerequisite> or <compile-dependency>.) We do this in a number of places in modules, and even have

to verify that we get it right. But it is pretty painful, and most developers have no idea they need to do this:

Furthermore, it introduces an artificial dependency between modules, when in fact m2 might run perfectly well without m1

We should have some other system of ensuring that one layer entry overrides another. The simplest thing I can think of
is to define a special numeric-valued file attribute 'weight' (default 0), where "heavier" entries override "lighter"
entries. (For compatibility, in the case of conflicting entries with the same weight, the "later" layer wins, as now.)
This could be interpreted in MultiFileSystem with no reference to the module system. So for example

---%<--- m1/src/m1/layer.xml
 <folder name="folder">
  <file name="data" url="m1-contents"/>
---%<--- m2/src/m2/layer.xml
 <folder name="folder">
  <file name="data" url="m2-contents">
    <attr name="weight" intvalue="100"/>

would suffice to ensure that Repo.gD().gDFS().fR("folder/data").getInputStream() would produce m2-contents rather than
m1-contents, regardless of module load order.

'priority' could also be used instead of 'weight' but I fear this might be mistaken for 'position', which is quite

ValidateLayerConsistencyTest could then be changed to just check that if multiple modules define the same file, each
specifies a different weight. This would be easy to test and failures would be easy to fix (either by removing duplicate
registrations or assigning weights according to priority).
Comment 1 Jesse Glick 2008-07-28 18:06:07 UTC
You could override findResource in ModuleLayeredFileSystem to make it affect just XML layers. This might be inefficient,
however (the default impl uses private infrastructure in MFS/MFO), and also would not work from unit tests that do not
load core.jar. Would probably be better to implement directly in MultiFileSystem.

One catch is that customizations, in $userdir/config/, should always override layer entries even if they specify a
weight. I suggest the code always pick the resource from layers[0] (the writable layer) if it exists, regardless of
weight in other layers. This ensures that after setting the content on a MFO, the observed content is what you just set.
Could also use createWritableOn to find the priority FS more accurately, taking care to ignore IOException's which are
meaningless in this context.
Comment 2 Jesse Glick 2008-07-28 19:28:29 UTC
Created attachment 65843 [details]
Possible patch
Comment 3 Jesse Glick 2008-07-28 19:31:19 UTC
I attached a patch which might work. (Only unit tested, not tried on a real example.) A full patch would also need API
changes & documentation, change of VLCT, fixup of modules to use the new attribute, and perhaps a change to
o.n.m.apisupport.project.layers to generate the weight attribute on new layer overrides (to e.g. 100 more than any
previous weight).
Comment 4 Jesse Glick 2009-07-22 20:14:13 UTC
Relates to apisupport.
Comment 5 rmichalsky 2009-07-23 07:30:25 UTC
Ok, I'll add weight generation once this feature is done.
Comment 6 rmichalsky 2009-08-12 12:00:11 UTC
Jirko, any possibility to get this into 6.8?
Comment 7 Jesse Glick 2010-02-22 08:40:10 UTC
It is probably better if I take over the base (non-apisupport) patch. I can work on VLCT and use that as a way to find layers in that need to be changed.
Comment 8 Jesse Glick 2010-02-22 15:13:31 UTC
Please review.
Comment 9 Jesse Glick 2010-02-22 15:16:16 UTC
Created attachment 94399 [details]
Revised patch

Includes filesystems changes to recognize the new 'weight' attr; API change documentation; rewritten VLCT test; and fixes to a few modules to make them pass the test (cluster.config=bloated) - to use weight in the few cases where overriding was actually intended, otherwise to not override.
Comment 10 Jesse Glick 2010-03-01 09:04:15 UTC
core-main #860290e5753e
Comment 11 Quality Engineering 2010-03-01 22:09:50 UTC
Integrated into 'main-golden', will be available in build *201003020200* on (upload may still be in progress)
User: Jesse Glick <>
Log: Issue #141925: provide a simpler way to declare which layer entries override others.
Comment 12 simpatico 2010-11-02 04:48:09 UTC

the dtd specified attr and not attributed as reported in the documentation page above:

    <folder name="my-snippets">
        <file name="common.xml" url="special-snippet.xml">
            <attribute name="weight" intvalue="100"/>
Comment 13 Quality Engineering 2010-11-03 03:58:11 UTC
Integrated into 'main-golden', will be available in build *201011030000* on (upload may still be in progress)
User: Jesse Glick <>
Log: #141925 apichanges tweak: <attr> not <attribute>.