[
https://issues.apache.org/jira/browse/LANG-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885582#action_12885582
]
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: 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-...@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.
