You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gary D. Gregory (Commented) (JIRA)" <ji...@apache.org> on 2012/02/29 15:39:57 UTC

[jira] [Commented] (LANG-788) SerializationUtils throws ClassNotFoundException when cloning primitive classes

    [ https://issues.apache.org/jira/browse/LANG-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13219247#comment-13219247 ] 

Gary D. Gregory commented on LANG-788:
--------------------------------------

Committed and added missing support to the patch for {{void.class}}
                
> 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
>             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