Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 23312 - Service registered with parent module's classloader
Service registered with parent module's classloader
Status: CLOSED DUPLICATE of bug 20663
Product: xml
Classification: Unclassified
Component: Code
3.x
PC Windows ME/2000
: P3 (vote)
: 3.x
Assigned To: David Strupl
issues@xml
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-09 23:55 UTC by Rich Unger
Modified: 2003-07-02 08:40 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Unger 2002-05-09 23:55:36 UTC
I've got a module (vxml) which depends on xml-tree.  xml-
tree contains a class called DoctypeCustomizer.  vxml's 
layer file contains:

    <folder name="Hidden">
        <file name="com-nuance-tools-voicexml-
tagmap.instance">
            <attr name="instanceClass" 
stringvalue="org.netbeans.modules.xml.tree.nodes.DoctypeCus
tomizer"/>
            <attr name="instanceCreate" 
methodvalue="org.netbeans.modules.xml.tree.nodes.DoctypeCus
tomizer.configure"/>
            <attr name="map" 
urlvalue="nbresloc:/com/nuance/tools/voicexml/resources/Voi
ceXMLMap.xml"/>
        </file>
    </folder>

The VoiceXMLMap.xml contains the names of classes, such as 
com.foo.vxml.MyCustomizer.  The DoctypeCustomizer class 
(specified in vxml's layer file) reads in VoiceXMLMap.vxml 
and instantiates com.foo.vxml.MyCustomizer.

This causes a ClassNotFoundDef error.  It seems that even 
though DoctypeCustomizer is referred to from the vxml 
module's layer file, it only has access to the xml-tree 
module's class loader.  When I replace the reference in 
vxml's layer file to a trivial subclass of 
DoctypeCustomizer that lives in the vxml module, it works.
Comment 1 Petr Hrebejk 2002-05-13 12:01:43 UTC
Jarda, please evaluate the bug.
Comment 2 Jaroslav Tulach 2002-05-13 14:22:27 UTC
I am not able to find the DoctypeCustomizer in
xml/tree-edit/src/org/netbeans/modules/xml/tree/nodes so I am moving
this to XML guys to decide what is wrong.
Comment 3 _ lkramolis 2002-05-13 14:34:03 UTC
It is not dirrectly XML module code, Rich enhances XML module in his side.

I think Rich has problems with tree of ClassLoaders. But I do not know
in which side problem could be. Rich do you have correct modules
dependencies?
Comment 4 Rich Unger 2002-05-13 18:32:59 UTC
I'm confused about what the "right" dependencies are.  My 
impression was that any classes referred to in a module's 
layer should be accessible from that module.  My vxml 
module depends on xml.tree.  vxml-layer.xml refers to a 
service with instanceClass=DoctypeCustomizer.  
DoctypeCustomizer is in xml.tree.  However, in this case 
it is being loaded by the vxml module.  Therefore, it is 
able to load the file VoiceXMLMap.xml, which resides in 
the vxml module.  VoiceXMLMap.xml contains the name of a 
class in the vxml module.  That is the class which does 
not get loaded.

So, we have a class in xml.tree (DoctypeCustomizer) which 
is being loaded during the vxml layer initialization, but 
cannot access classes in the vxml module.

When I add a new class to the vxml module, which is a 
trivial subclass of DoctypeCustomizer, and refer to that 
subclass in vxml-layer.xml instead of referring to 
DoctypeCustomizer, it works.  This seems to me to be an 
unnecessary limitation of the services mechanism.

I've posted my patched xml.tree code to 
http://ungerware.dhs.org/~rich/xmltreepatch.zip
It is not complete as yet, which is why I've not yet 
submitted it the standard way.
Comment 5 Rich Unger 2002-05-14 21:22:59 UTC
At Jesse's suggestion, I tried explicitly using 
TopManager.systemClassPath in my Class.forName call, and 
it worked.  This seems odd to me, as the "current" 
classloader I would think should be the same as what gets 
returned by TopManager.systemClassPath.

Perhaps it is a bug, or perhaps I'm misunderstanding the 
subtleties of module classloaders.  I'll leave it to you 
whether this issue can be closed.  The workaround is 
sufficient for my needs.
Comment 6 David Strupl 2002-05-15 10:28:06 UTC
If I understand it right what you are asking was implemented into 3.4
 as issue 20663. Marking this as duplicate. Not available in 3.3.1 -
sorry.

*** This issue has been marked as a duplicate of 20663 ***
Comment 7 Jesse Glick 2002-05-15 18:49:13 UTC
Well, #20663 simply makes it more convenient for people using non-NB
external libraries such as JAXP: you can use
Thread.currentThread().getContextClassLoader() instead of the
NB-specific TopManager.getDefault().systemClassLoader(). So this is
not exactly a duplicate I suppose.

The basic problem is the same with or without #20663:
Class.forName(String) looks in the *caller's* classloader, which will
only load classes from the classpath, the caller's module, and modules
the caller's module depends on. Other modules, including those
depending on the caller's module, will *not* be accessible here. You
must pass in the ClassLoader explicitly if you want them to be. This
is not a bug, it is just how classloaders work. The calling code,
which I guess would be in the XML Tree module (?) is responsible for
passing a suitable classloader to whatever call is used to load
classes. Purely an XML module issue.
Comment 8 Martin Schovanek 2002-11-06 13:34:35 UTC
VERIFIED
Comment 9 Quality Engineering 2003-07-02 08:40:37 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.


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