You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Sven Ludwig (JIRA)" <ji...@apache.org> on 2010/07/06 14:25:49 UTC
[jira] Commented: (LANG-626) object cloning with SerializationUtils
has classloader problems with no workaround
[ https://issues.apache.org/jira/browse/LANG-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885516#action_12885516 ]
Sven Ludwig commented on LANG-626:
----------------------------------
I encountered the same problem within the Tomcat-Container and my web-application. commons-lang is on the shared classpath, but the objects to clone are in the web-application.
I vote for this issue to be fixed in such a way that the developer does not need to do more than call the right method on SerializationUtils. In these modern days it would be nice to have a working clone tool that saves one the potentially large hassle of keeping track of deep-clone methods or deep-clone copy-constructors.
> object cloning with SerializationUtils has classloader problems with no workaround
> ----------------------------------------------------------------------------------
>
> Key: LANG-626
> URL: https://issues.apache.org/jira/browse/LANG-626
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
> Environment: WebLogic 10.3
> Reporter: Ernest Pasour
>
> In WebLogic 10.3, commons_lang is included on the main classpath, trumping the commons_lang on a webapp classpath (in webinf/lib). This causes ClassNotFoundException errors when using SerializationUtils.clone() because Java serialization uses the classloader of the current class (class invoked from) when doing serialization. Java serialization does not respond to the thread context classloader.
> Fix: The following web page suggests a fix (including the full source code) that honors the context classloader if set. I don't know if this is the ideal solution, but at least it allows the problem to be worked around without affecting working behavior for existing clients.
> http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg44524.html
> Workaround: There is a flag to set on weblogic that inverts the classloader. *HOWEVER*, this only works if the webapp does not need certain xml jars. Otherwise, WebLogic will fail to start because *it* has classloader issues. Therefore, this is not an acceptable workaround.
> Another workaround: The only workaround I know of is to copy the SerializationUtils class into a different package in my app so that the proper invocation context will be used for serialization. This is very undesirable.
> I found these 3 bugs in the database that all seem to be the same problem.
> https://issues.apache.org/jira/browse/OJB-140
> https://issues.apache.org/jira/browse/LANG-241
> https://issues.apache.org/jira/browse/JS2-831
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.