[
https://issues.apache.org/jira/browse/YOKO-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492009
]
Rick McGuire commented on YOKO-258:
-----------------------------------
Absolutely. Consider a server worker thread. On one call to retrieve the map,
it will have a thread context class loader set for one application. The next
time this routine is called, it can have one set for a different application.
The association here is between class loader instances and a map, not an
individual thread and a map. Your change creates a single association based on
the context classloader that's currently set the first time this code is called
on a given thread. But the thread context classloader is a settable value, so
it's likely to change. In a server environment in particular, it likely NOT to
be the same from call-to-call.
> 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.
