[
https://issues.apache.org/jira/browse/YOKO-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492002
]
Sergey Salishev commented on YOKO-258:
--------------------------------------
Not sure I understand your comment.
>From Thread.getContent ClassLoader JavaDoc:
"Returns the context ClassLoader for this Thread. The context ClassLoader is
provided by the creator of the thread for use by code running in this thread
when loading classes and resources. If not set, the default is the ClassLoader
context of the parent Thread. The context ClassLoader of the primordial thread
is typically set to the class loader used to load the application. "
As I understand this text there is exactly one content ClassLoder per thread.
Do yo think the getContent ClassLoader can return different ClassLoader objects
for the same thread?
> Bad reference to ClassLoader.classes in
> org.apache.yoko.rmi.util.ClassLoaderLocal static initializer
> ----------------------------------------------------------------------------------------------------
>
> Key: YOKO-258
> URL: https://issues.apache.org/jira/browse/YOKO-258
> Project: Yoko - CORBA Server
> Issue Type: Bug
> Reporter: Vasily Zakharov
> Assigned To: Lars Kühne
> Fix For: v1.0.0
>
>
> org.apache.yoko.rmi.util.ClassLoaderLocal class contains the following line
> in its static initializer:
> classes_vector = ClassLoader.class.getDeclaredField("classes");
> This line references the 'classes' field in class java.lang.ClassLoader, and
> that field is not documented by API JavaDoc and may be absent in particular
> Java VM/classlib implementations, for example it's absent in Apache Harmony.
> As the result of this issue, the classes
> org.apache.yoko.rmi.util.ClassLoaderLocal and
> org.apache.yoko.rmi.impl.PortableRemoteObjectExtImpl fail to load with
> NoSuchFieldException, on those implementations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
