[
https://issues.apache.org/jira/browse/LANG-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893180#action_12893180
]
Conny Kreyßel commented on LANG-626:
------------------------------------
@Mark:
Whats about a OSGi environment? There are many classloaders around and i could
not copy them to every plugin it use commons-lang.
Why not add all SerializationUtils methods a second method with classloader
attribute and then resolve classes within the ObjectOutputStream with the
submitted classloader and/or ContextClassLoader?
> 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
> Attachments: ContextClassLoaderAwareCloneMethod.zip
>
>
> 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-...@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.
