[
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/[email protected]/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.
