Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 19622 - Refuse random packages to modules that have not asked for them
Refuse random packages to modules that have not asked for them
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Module System
3.x
PC Linux
: P2 (vote)
: 3.x
Assigned To: Jesse Glick
issues@platform
:
Depends on: 19620
Blocks: 17815 19621 19682 20270 23399 26042
  Show dependency treegraph
 
Reported: 2002-01-20 15:30 UTC by Jesse Glick
Modified: 2008-12-23 08:37 UTC (History)
8 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Proposed patch (36.08 KB, patch)
2002-02-14 18:00 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 2002-01-20 15:30:41 UTC
If a module has not declared a dependency on org.netbeans.core/1, it ought not
be able to access org.netbeans.core.** classes. The module classloader should
refuse access.

If it does not have a package dependency on org.apache.regexp, such classes
should be refused.

XML: APIs (DOM, SAX, JAXP) should be accessible to all modules, part of the
classpath. However particular impls (Crimson, Xerces) should be accessible only
to modules requesting a package dependency (i.e. not by default). That is, a
module should be able to have a Class-Path on ext/xerces-3.0beta99.jar and not
have any further problems.

jh.jar is being taken care of as part of JavaHelp separation, see issue #19620.
Comment 1 Jesse Glick 2002-01-24 17:03:20 UTC
Don't forget about ProxyClassLoader.hacky method:

    // XXX fix later!
    // Currently ICE browser JAR includes a copy of many XML classes,
including
    // two classes in org.w3c.dom.events which are not in Xerces for
some reason.
    // This is a temporary workaround to permit these two classes to
be loaded
    // by the ICE browser even though there is package skew going on.
    private static final boolean hacky(final String pkg) {
        return pkg.equals("org.w3c.dom.events") || // NOI18N
               pkg.equals("org/w3c/dom/events"); // NOI18N
    }
Comment 2 _ pkuzel 2002-01-30 10:34:18 UTC
Is not following requirement the same?
"Let module classloader always prefer loading from explicit declared
locations over implicit location such as classpath and bootclasspath."

Also another manifest entry can modify the _always_ meaning but it
just nice to have; always seems to me the right way. 
Comment 3 Jesse Glick 2002-01-30 13:11:43 UTC
Maybe. However it is the reverse of the normal classloader rule and
thus potentially confusing. Also it may be incompatible if applied
generally.

Anyway access does need to be blocked to classes for which the module
has no declared dependency.
Comment 4 _ pkuzel 2002-02-12 13:56:09 UTC
I would like to explicitly show one case.

Module A depends on module B and xerces2.0.0 library
Module B depends on xerces1.4.4.jar library
Module C dependes on xerces2.0.0 library

A's classloader should use following preference order
  1) load from module jar else
  2) load from xerces2.0.0 library else
  3) delegate to B's classloader else
  4) delegate to system classloader or CNFE

It is probably ineffecient as xerces2.0.0 library may be loaded by
multiple classloaders independently. Introducing classloader per
library/resource could solve it:
  1) load from module jar else
  2) delegate to xerces2.0.0 library classloader else
  3) delegate to B's classloader else
  4) delegate to system classloader or CNFE
Comment 5 Jesse Glick 2002-02-12 16:14:41 UTC
Ick, I don't like the A -> B dependency here at all. If B uses some
version of Xerces and A depends on B, by default A should look for
classes in B first. The scenario you describe is a mess IMHO and no
module author should get this behavior by default. In addition, there
are serious compatibility considerations here: current behavior is
that classes loadable from a module are visible for dependent modules
and used preferentially, and we must maintain that default.

Issue #19621 could be helpful if you are using a private extension
from B: B could hide it.

I'm not sure how things could work if Xerces were an autoload library.
If #19621 is interpreted more broadly to mean that a module controls
not only exporting of classes loaded from its JAR and any extension
JARs, but classes it can itself see from its own dependencies, then B
can decide whether to expose its dependency on Xerces autoload to
other modules - probably it would want to hide it as an implementation
detail. In that case, A by dependending on B always forces Xerces
1.4.4 to be loaded; but will only be able to *see* classes from Xerces
1.4.4 if it also declares a direct dependency on that autoload. It
might declare a dependency on Xerces 2.0.0 autoload and use that instead.
Comment 6 Jesse Glick 2002-02-13 08:56:56 UTC
MouseEvent and UIEvent (present in icebrowserlitebean.jar) are missing
from our current xerces.jar, as well as xerces.jar version 2.0.0.
These use the org.w3c.dom.views package which does not appear to be in
Xerces.
Comment 7 _ pkuzel 2002-02-13 09:26:15 UTC
These events are a part of proposed dom.jar package. Its content can
be compiled from Apache's xml-commons or downloaded with DOM2 specs.
(Still pending legal approval).
Comment 8 Jesse Glick 2002-02-13 14:28:35 UTC
Good! That will simplify things.
Comment 9 Jesse Glick 2002-02-14 11:20:01 UTC
I am working on this, starting in ProxyClassLoader. May have to make a
branch, TBD.
Comment 10 Jesse Glick 2002-02-14 18:00:27 UTC
Created attachment 4709 [details]
Proposed patch
Comment 11 Jesse Glick 2002-02-14 18:08:16 UTC
Have patch. Note that there are a number of modules in nb_all which
illegally used classes or resources in org.netbeans.core. In these
cases a dependency must be declared or errors will result.

I plan to commit such dependencies to manifests, but module owners
should check to see if they can remove the dependencies. I am CCing
modules for which a new dependency was required where I do not believe
that the use of the core class(es) is really required or advisable.

There are other modules where I needed to add a dependency to prevent
errors, but where that dependency looked reasonable and intentional,
and it was just forgotten in the manifest.
Comment 12 Jesse Glick 2002-02-18 13:50:43 UTC
Done.

In directory ant:
committed   * Up-To-Date  1.42        ant/manifest.mf
In directory apisupport:
committed   * Up-To-Date  1.59        apisupport/manifest.mf
In directory corba:
committed   * Up-To-Date  1.42        corba/manifest.mf
In directory core:
In directory core/src:
In directory core/src/org:
In directory core/src/org/netbeans:
In directory core/src/org/netbeans/core:
In directory core/src/org/netbeans/core/modules:
committed   * Up-To-Date  1.21       
core/src/org/netbeans/core/modules/Module.java
committed   * Up-To-Date  1.4        
core/src/org/netbeans/core/modules/ModuleInstaller.java
committed   * Up-To-Date  1.22       
core/src/org/netbeans/core/modules/ModuleManager.java
committed   * Up-To-Date  1.16       
core/src/org/netbeans/core/modules/ModuleSystem.java
committed   * Up-To-Date  1.27       
core/src/org/netbeans/core/modules/NbInstaller.java
committed   * Up-To-Date  1.10       
core/src/org/netbeans/core/modules/ProxyClassLoader.java
In directory debuggercore:
In directory debuggercore/src:
In directory debuggercore/src/org:
In directory debuggercore/src/org/netbeans:
In directory debuggercore/src/org/netbeans/modules:
In directory debuggercore/src/org/netbeans/modules/debugger:
In directory debuggercore/src/org/netbeans/modules/debugger/support:
In directory debuggercore/src/org/netbeans/modules/debugger/support/nodes:
committed   * Up-To-Date  1.26       
debuggercore/src/org/netbeans/modules/debugger/support/nodes/DebuggerWindow.java
In directory editor:
committed   * Up-To-Date  1.43        editor/manifest.mf
In directory externaleditor:
committed   * Up-To-Date  1.11        externaleditor/manifest.mf
In directory form:
committed   * Up-To-Date  1.47        form/manifest.mf
In directory i18n:
committed   * Up-To-Date  1.45        i18n/manifest.mf
In directory jarpackager:
committed   * Up-To-Date  1.46        jarpackager/manifest.mf
In directory java:
committed   * Up-To-Date  1.52        java/manifest.mf
In directory objectbrowser:
committed   * Up-To-Date  1.42        objectbrowser/manifest.mf
In directory openide:
In directory openide/api:
In directory openide/api/doc:
In directory openide/api/doc/org:
In directory openide/api/doc/org/openide:
In directory openide/api/doc/org/openide/modules:
In directory openide/api/doc/org/openide/modules/doc-files:
committed   * Up-To-Date  1.70       
openide/api/doc/org/openide/modules/doc-files/api.html
In directory web:
In directory web/advanced:
committed   * Up-To-Date  1.47        web/advanced/manifest.mf
In directory web/taglibed:
committed   * Up-To-Date  1.8         web/taglibed/manifest.mf
In directory workspaceswitcher:
committed   * Up-To-Date  1.2         workspaceswitcher/manifest.mf


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo