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 248216 - Allow different implementations of the GlobalPathRegistry
Summary: Allow different implementations of the GlobalPathRegistry
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Classpath (show other bugs)
Version: 8.1
Hardware: All All
: P2 normal (vote)
Assignee: apireviews
URL:
Keywords: API, API_REVIEW_FAST
Depends on:
Blocks:
 
Reported: 2014-10-27 18:09 UTC by Tomas Zezula
Modified: 2014-11-21 03:50 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
Exception Reporter:

Attachments
The diff file (23.31 KB, application/octet-stream)
2014-10-27 18:09 UTC, Tomas Zezula 		Details
Difffile (29.05 KB, application/octet-stream)
2014-11-06 13:18 UTC, Tomas Zezula 		Details
Diff file (29.05 KB, patch)
2014-11-06 13:23 UTC, Tomas Zezula 		Details | Diff
Show Obsolete (2) Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2014-10-27 18:09:33 UTC 
Created attachment 150135 [details]
The diff file

Make GlobalPathRegistry pluggable by SPI to allow different implementations.
The SPI interface is looked up from default Lookup.
Comment 1 Tomas Zezula 2014-11-06 13:18:27 UTC 
Created attachment 150325 [details]
Difffile
Comment 2 Tomas Zezula 2014-11-06 13:23:20 UTC 
Created attachment 150326 [details]
Diff file

The original patch introduced semantic incompatibility.
In order to listen on GlobalPathRegistry the client code needed to hold the GPR instance. Unfortunately on several places in the IDE the GPR listening is done by:
GlobalPathRegistry.getDefault().addGlobalPathRegistryListener(this);
Such a code would be broken.
The SPI was changed to keep the semantic compatibility.
Comment 3 Svata Dedic 2014-11-07 13:49:45 UTC 
The patch itself seems OK to me; I would recommend to change javadoc (again, semantic-incompatibly) and give an explicit warning to clients to *not* keep an instance of GPR.getDefault(), as it may change based on Lookup context.

I've found some such usages:
contrib/portalpack.servers.base_psframework/src/org/netbeans/modules/portalpack/servers/core/common/ServerLogSupport.java
contrib/gsf/src/org/netbeans/modules/gsfret/source/GlobalSourcePath.java
j2ee.sun.appsrv81/src/org/netbeans/modules/j2ee/sun/ide/j2ee/LogHyperLinkSupport.java
tomcat5/src/org/netbeans/modules/tomcat5/util/LogViewer.java
tomcat5/src/org/netbeans/modules/tomcat5/util/ServerLog.java

The following clients keep GPR instance in a singleton:
parsing.indexing/src/org/netbeans/modules/parsing/impl/indexing/PathRegistry.java
java.sourceui/src/org/netbeans/modules/java/source/ui/OpenProjectFastIndex.java
javadoc/src/org/netbeans/modules/javadoc/search/JavadocRegistry.java

None of the above should do any harm in desktop NetBeans, where the context (and thus GPR) is just one.
Comment 4 Tomas Zezula 2014-11-07 21:03:07 UTC 
OK. I will update javadoc and fix relevant usages.

The parsing.indexing/src/org/netbeans/modules/parsing/impl/indexing/PathRegistry.java needs default composite GPR so it's OK that it holds the instance. But it has to be started from the SessionContextListener.
Comment 5 Tomas Zezula 2014-11-10 07:02:24 UTC 
Fixed jet-main ec84953fb5cd
Comment 6 Quality Engineering 2014-11-21 03:50:50 UTC 
Integrated into 'main-silver', will be available in build *201411210001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/ec84953fb5cd
User: Tomas Zezula <tzezula@netbeans.org>
Log: #248216:Allow different implementations of the GlobalPathRegistry