You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Ernest Pasour (JIRA)" <ji...@apache.org> on 2010/06/18 21:55:23 UTC
[jira] Created: (LANG-626) object cloning with SerializationUtils
has classloader problems with no workaround
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.
[jira] Updated: (LANG-626) object cloning with SerializationUtils
has classloader problems with no workaround
Posted by "Sven Ludwig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sven Ludwig updated LANG-626:
-----------------------------
Attachment: ContextClassLoaderAwareCloneMethod.zip
Proposal of additional method for the SerializationUtils that works with the current thread context ClassLoader. Fixes the problem under Tomcat.
> 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-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.
[jira] Commented: (LANG-626) object cloning with SerializationUtils
has classloader problems with no workaround
Posted by "Ernest Pasour (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881671#action_12881671 ]
Ernest Pasour commented on LANG-626:
------------------------------------
Yes, that appears to be the same thread I was referring to.
I agree that it seems like WebLogic should repackage the code to avoid this issue, but I also agree that's not likely to happen. :(
> 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.
[jira] Issue Comment Edited: (LANG-626) object cloning with
SerializationUtils has classloader problems with no workaround
Posted by "Conny Kreyßel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893180#action_12893180 ]
Conny Kreyßel edited comment on LANG-626 at 7/28/10 9:55 AM:
-------------------------------------------------------------
@Mark:
Whats about a OSGi environment? There are many classloaders around and i could not copy commons-lang.jar 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?
was (Author: azgard):
@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-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.
[jira] Commented: (LANG-626) object cloning with SerializationUtils
has classloader problems with no workaround
Posted by "Conny Kreyßel (JIRA)" <ji...@apache.org>.
[ 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-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.
[jira] Issue Comment Edited: (LANG-626) object cloning with
SerializationUtils has classloader problems with no workaround
Posted by "Sven Ludwig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12885890#action_12885890 ]
Sven Ludwig edited comment on LANG-626 at 7/7/10 5:01 AM:
----------------------------------------------------------
Proposal of additional method for the SerializationUtils that works with the current thread context ClassLoader. Fixes the problem under Tomcat. Attached ContextClassLoaderAwareCloneMethod.zip with two java files. Note that the code makes use of generics, but it can be easily adjusted to work under Java 1.4.
was (Author: sludwig):
Proposal of additional method for the SerializationUtils that works with the current thread context ClassLoader. Fixes the problem under Tomcat.
> 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-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.
[jira] Commented: (LANG-626) object cloning with SerializationUtils
has classloader problems with no workaround
Posted by "Sven Ludwig (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (LANG-626) object cloning with SerializationUtils
has classloader problems with no workaround
Posted by "Mark Thomas (JIRA)" <ji...@apache.org>.
[ 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-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.
[jira] Commented: (LANG-626) object cloning with SerializationUtils
has classloader problems with no workaround
Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881099#action_12881099 ]
Henri Yandell commented on LANG-626:
------------------------------------
mail-archive isn't working for me right now; I'm guessing it's this thread from 2004:
http://commons.markmail.org/thread/trfdrjeb6qohru7p
The right solution, imo, is for Weblogic to do what all containers do/should do and use a package name rewrite at build time so they have their dependencies in private space. Presumably not likely to happen.
Need to look at the attached mailing list code, also consider the option in LANG-241 that asked for an optional ClassLoader parameter.
> 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.