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 190901 - Allow only explicit delegation to classpath like in OSGi
Summary: Allow only explicit delegation to classpath like in OSGi
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 6.x
Hardware: Other Linux
: P1 normal (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: API_REVIEW_FAST
Depends on: 194044
Blocks:
  Show dependency tree
 
Reported: 2010-10-11 11:37 UTC by Jaroslav Tulach
Modified: 2011-01-10 15:40 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Introduces netbeans.bootdelegation property (9.04 KB, patch)
2010-10-11 11:37 UTC, Jaroslav Tulach
Details | Diff
Needed refinement (2.42 KB, patch)
2010-10-20 14:22 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 2010-10-11 11:37:55 UTC
Created attachment 102347 [details]
Introduces netbeans.bootdelegation property

The team that is using Netbinox seems to have some duplicated classes on classpath as well as in bundles. However these classes are not loaded by Thread.currentThread().getContextClassLoader() in classical Equinox mode. Only in Netbinox they do.

This is caused by Netbinox (like NetBeans) preferring the classpath classes. I considered many solutions, but the simplest one seems to be to prevent the delegation altogether just like OSGi does.
Comment 1 Jaroslav Tulach 2010-10-11 11:38:51 UTC
I'd like this to be available in some patch for 6.9.1 version.
Comment 2 Jaroslav Tulach 2010-10-13 17:03:49 UTC
core-main#aa968894426f
Comment 3 Jaroslav Tulach 2010-10-13 17:35:49 UTC
Merged to release691 branch:
http://hg.netbeans.org/releases/rev/341beaa4ff6a
Comment 4 Jesse Glick 2010-10-13 17:49:18 UTC
API reviews are supposed to be open for comments for seven days.

Doesn't this essentially duplicate the functionality of OpenIDE-Module-Hide-Classpath-Packages?

I am not sure 'devel' stability is appropriate when there is just one known use case.
Comment 5 Jaroslav Tulach 2010-10-20 14:22:38 UTC
Created attachment 102519 [details]
Needed refinement
Comment 6 Jaroslav Tulach 2010-10-20 14:44:07 UTC
You are right, I did not wait as long as required. I am sorry for that, but I got a feeling I cannot expect any comments.

Anyway, I needed to provide additional refinement. The delegation from NetBeans module to OSGi bundles was broken when running with netbeans.bootdeletation property. 
release692: http://hg.netbeans.org/releases/rev/93cd83a82b68
core-main: http://hg.netbeans.org/core-main/rev/922ea9bca709

Re. duplicating functionality: Not exactly. The OpenIDE-Module-Hide-Classpath-Packages is still the preferred way for doing these sorts of tricks. The property is more for testing purposes. E.g. when somebody external to the module JARs tries to load them preferably from a module classloader and not from a classpath. We could use this in NbModuleSuite instead of special classloader that hides everything what is on classpath. 

Right now the other usage is in another testing framework. I guess for these two testing frameworks we could change the stability category to friend, if you insist on it.
Comment 7 Jesse Glick 2010-10-20 14:48:07 UTC
"Friend" stability sounds more appropriate, though it's just a matter of labeling I guess.
Comment 8 Marian Mirilovic 2010-10-25 07:27:17 UTC
Jarda, could you please verify this fix in NB 6.9.1 + Patch 2 ? Thank sin advance.
Comment 9 Jaroslav Tulach 2010-10-29 16:15:36 UTC
Works like a charm.