commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary D. Gregory (Resolved) (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (LANG-788) SerializationUtils throws ClassNotFoundException when cloning primitive classes
Date Wed, 29 Feb 2012 14:39:57 GMT

     [ https://issues.apache.org/jira/browse/LANG-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gary D. Gregory resolved LANG-788.
----------------------------------

       Resolution: Fixed
    Fix Version/s: 3.2
         Assignee: Gary D. Gregory

In SVN.
                
> SerializationUtils throws ClassNotFoundException when cloning primitive classes
> -------------------------------------------------------------------------------
>
>                 Key: LANG-788
>                 URL: https://issues.apache.org/jira/browse/LANG-788
>             Project: Commons Lang
>          Issue Type: Bug
>    Affects Versions: 3.1
>            Reporter: René Link
>            Assignee: Gary D. Gregory
>             Fix For: 3.2
>
>         Attachments: LANG-788
>
>
> If a serializable object contains a reference to a primitive class, e.g. int.class or
int[].class, the SerializationUtils throw a ClassNotFoundException when trying to clone that
object.
> {noformat}
> import org.apache.commons.lang3.SerializationUtils;
> import org.junit.Test;
> public class SerializationUtilsTest {
> 	
> 	@Test
> 	public void primitiveTypeClassSerialization(){
> 		Class<?> primitiveType = int.class;
> 		
> 		Class<?> clone = SerializationUtils.clone(primitiveType);
> 		assertEquals(primitiveType, clone);
> 	}
> }
> {noformat} 
> The problem was already reported as a java bug http://bugs.sun.com/view_bug.do?bug_id=4171142
and ObjectInputStream is fixed since java version 1.4.
> The SerializationUtils problem arises because the SerializationUtils internally use the
ClassLoaderAwareObjectInputStream that overrides the ObjectInputStream's
> resoleClass method without delegating to the super method in case of a ClassNotFoundException.
> I understand the intention of the ClassLoaderAwareObjectInputStream, but this implementation
should also implement a fallback to the original implementation.
> For example:
> {noformat}
>         protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException,
ClassNotFoundException {
>             String name = desc.getName();
>             try {
>                 return Class.forName(name, false, classLoader);
>             } catch (ClassNotFoundException ex) {
>             	try {
>             	     return Class.forName(name, false, Thread.currentThread().getContextClassLoader());
>             	} catch (Exception e) {
> 		     return super.resolveClass(desc);
> 		}
>             }
>         }
> {noformat}
> Here is the code in ObjectInputStream that fixed the java bug.
> {noformat}
>     protected Class<?> resolveClass(ObjectStreamClass desc)
> 	throws IOException, ClassNotFoundException
>     {
> 	String name = desc.getName();
> 	try {
> 	    return Class.forName(name, false, latestUserDefinedLoader());
> 	} catch (ClassNotFoundException ex) {
> 	    Class cl = (Class) primClasses.get(name);
> 	    if (cl != null) {
> 		return cl;
> 	    } else {
> 		throw ex;
> 	    }
> 	}
>     }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message