[
https://issues.apache.org/jira/browse/YOKO-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492008
]
Sergey Salishev commented on YOKO-258:
--------------------------------------
Oops. I've run the simple test and it shows it's possible to change the the
content ClassLoader at any time tin Thread life cycle. I thought it can be
changed only before the thread is started. I was wrong.
So the only ways to correct the fix I see now are ether synchronize the
localMaps access or use fine grained hash map from java.util.concurent
> 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.
