commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (JIRA)" <>
Subject [jira] Commented: (LANG-626) object cloning with SerializationUtils has classloader problems with no workaround
Date Tue, 06 Jul 2010 16:21:53 GMT


Mark Thomas commented on LANG-626:

w.r.t. WebLogic: I assume folks using it have a support contract and since this is a clear
bug I'd recommend using your support contract to pressure Oracle into a fix. Yes it takes
time and requires generally making a nuisance of yourself but it can be done - at least I
got a handful of Oracle app server bugs fixed that way.

w.r.t. Tomcat: if commons-lang is on the common class path it is because the user put it there.
Tomcat does not use and does not ship with commons-lang and to the best of my recollection
never has. The correct solution in this case is to put commons-lang where it belongs - in
WEB-INF/lib. This would also work for any spec compliant servlet container.

In terms of the original proposed patch, I am not a fan of configuration via system properties
unless there is no other choice. I'm not convinced that is the case here. I would also recommend
testing to ensure that this patch does not trigger a class-loader memory leak. It shouldn't,
but based on past experience I wouldn't be surprised if it did. Assuming no memory leak, the
only remaining argument against the patch is one of bloat. Should we add code to commons-lang
just to work around another product's bugs? My general view is that we shouldn't so I'd be
-0 for applying this patch.

> object cloning with SerializationUtils has classloader problems with no workaround
> ----------------------------------------------------------------------------------
>                 Key: LANG-626
>                 URL:
>             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
> 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.  

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message