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 198508 - Ability to provide additional Layers
Summary: Ability to provide additional Layers
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 7.0
Hardware: Other Linux
: P1 normal (vote)
Assignee: Jaroslav Tulach
Depends on: 213786
  Show dependency tree
Reported: 2011-05-11 11:58 UTC by Jaroslav Tulach
Modified: 2012-06-07 23:40 UTC (History)
4 users (show)

See Also:
Exception Reporter:

Introducing LayersProvider interface (57.23 KB, patch)
2011-05-30 18:02 UTC, Jaroslav Tulach
Details | Diff
LayersProvider is ready for future evolution (57.26 KB, patch)
2012-02-01 09:08 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2011-05-11 11:58:54 UTC
Ergonomics, but not only ergonomics would benefit from ability to register additional layer XML files into the content of system directory. The system would then include these layers into BinaryFS cache, offering effective access to the content on subsequent start.
Comment 1 Jaroslav Tulach 2011-05-11 12:01:32 UTC
Interface like 

public interface org.openide.modules.LayerProvider {
  void findLayers(Collection<? super URL> toAdd);

could work. I am not sure how to verify, validate and invalidate the caches.
Comment 2 Jaroslav Tulach 2011-05-30 18:02:15 UTC
Created attachment 108605 [details]
Introducing LayersProvider interface

Ergnomics or other systems that somehow extract layers from a list of modules will implement the interface and return list of layer URLs.

Reviewers, please review. Hřebejku, please test.
Comment 3 Petr Hrebejk 2011-06-06 17:33:16 UTC
[PH01] Thinking about it. Now in order to generate content of the FS. We create a set of XML documents (usually in form of DOM) then print them (into memory) and put them into the FS API. The implementation likely parses them again into DOM and then creates the files and folders on the FS. IMO it would be more effective if we would have an API for building content of the FS directly. I.e. creating the files folders. Not only it would be faster but it could also permit for e.g. checking if given file already exists.
Comment 4 Jesse Glick 2011-07-21 13:41:09 UTC
Is there a concrete use case for this? It is hard to evaluate without more details.

In particular, what is wrong with the existing SPI (bug #26338) which allows you to register a FileSystem into global Lookup? (Which already addresses PH01 as I understand it.) The only thing missing currently is cache integration, but I do not see any reason why that could not be added, given some reflective pseudoattribute syntax such as in the fix of bug #120724. (*)

There are also known use cases for dynamic changes to the set of injected layers, which of course should not be cached; ActiveConfigAction in the project system uses this, and describes how to use this to switch the main menu bar.

(*) #120724 looks to implement raw:* even on getAttribute, though that is apparently undocumented. WritableXMLFileSystem in apisupport uses a more general literal:* syntax which bypasses java.util.reflect, useful when the classes in question cannot be accessed at development time.
Comment 5 Jaroslav Tulach 2011-07-22 05:38:14 UTC
Ergonomics is the primary usecase. Rather than having its own MultiFS and BinaryFS, with LayersProvider interface ergonomics could merge its data into the single shared BinaryFS cache. In the light of bug 199740 (which shows that each delegate in MultiFS comes with a cost), this would make the system more effective.

Hřebejk has secondary usecase. He is converting parts of JSR 198 extension.xml to FileObjects, so they can be stored in a cache and don't have to be parsed on every start. 

For Hřebejk PH01 makes sense, as he does not have the layer.xml yet. Ergonomics don't need PH01 at all.

Actually when thinking about the builder API, I was more attracted by:

not only it would give shared API for compiletime & runtime, but it would be easy to verify that the runtime behaves correctly.
Comment 6 Jaroslav Tulach 2012-02-01 09:08:59 UTC
Created attachment 115423 [details]
LayersProvider is ready for future evolution

Hřebejk's usecase is no longer a blocker as Hřebejk is using BinaryFS directly, see bug 206072). Still, it makes sense to change the LayersProvider class to be more flexible for the future - e.g. allow builders of content rather than URLs in the future.

Here is the new version. That has a method that takes Collection rather than one to return it. In future we can introduce new method that will take Collection and a builder or only a builder interface and as a fallback delegate to the already existing method.

I'd like to integrate on Friday.
Comment 7 Jaroslav Tulach 2012-02-01 09:15:18 UTC
I've created a branch
Comment 8 Jesse Glick 2012-02-01 20:27:47 UTC
Do not have time to review in full detail before then but quickly:

[JG01] Suggest "LayerProvider" rather than "LayersProvider" (compound nouns in English usually cannot use internal plural forms).

[JG02] Maybe include some kind of a key (assignable to Serializable? or String?) permitting a provider to help control when the cache should be rebuilt, in case something more than module list matters.

[JG03] Passing in a Collection<? super T> is a little risky; what if the provider calls clear() etc. despite the Javadoc? Is addAll OK? Safer to pass in a callback interface with an add(T) method.

[JG04] Existing documentation mentioning inserting a FS into default lookup should suggest using this instead.

[JG05] Document behavior w.r.t. propagation of masks.
Comment 9 Jaroslav Tulach 2012-02-02 10:12:14 UTC
changeset:   212189:2eb1ef99ae1b
branch:      layers-provider-198508
parent:      212062:53d2dfd6e7a1
user:        Jaroslav Tulach <>
date:        Thu Feb 02 10:32:58 2012 +0100
summary:     JG01: using singular name

changeset:   212190:83cd1016db1c
branch:      layers-provider-198508
user:        Jaroslav Tulach <>
date:        Thu Feb 02 10:41:11 2012 +0100
summary:     JG03: To shield against context.clear() and similar call, let's use a dedicated array for each call to registerLayers

changeset:   212191:83bcf0e02437
branch:      layers-provider-198508
user:        Jaroslav Tulach <>
date:        Thu Feb 02 11:07:50 2012 +0100
summary:     JG04: Better and crosslinked javadoc

changeset:   212192:c6f85f7f5467
branch:      layers-provider-198508
tag:         tip
user:        Jaroslav Tulach <>
date:        Thu Feb 02 11:10:21 2012 +0100
summary:     JG05: Documented where the layers go. The ergonomics usecase needs them below standard module layers.

Re. JG02 - none of existing usecases needs that, will add it when needed.

Still on track to integrate tomorrow.
Comment 10 Jaroslav Tulach 2012-02-06 14:43:26 UTC
Merged as ergonomics#69a8a720a65d