[ https://issues.apache.org/jira/browse/PIG-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525809#comment-13525809 ]
Julien Le Dem commented on PIG-2815: ------------------------------------ 0.11/trunk sounds good to me > class loader management in PigContext > ------------------------------------- > > Key: PIG-2815 > URL: https://issues.apache.org/jira/browse/PIG-2815 > Project: Pig > Issue Type: Bug > Components: impl > Affects Versions: 0.9.0 > Reporter: Raghu Angadi > Assignee: Raghu Angadi > Fix For: 0.11 > > Attachments: PIG-2815-branch-0.9.patch, PIG-2815-branch-0.9.patch, > PIG-2815.patch, PIG-2815.patch > > > The way {{PigContext.classloader}} and resolveClassName() are managed can > lead to strange class loading issues, especially when not all {{register}} > statements are at the top (example in the first comment). > Two factors contribute to this: sometimes only one of them and sometimes > together: > # a new classloader (CL) is created after registering each jar. > ** but the new jar's parent is the root CL rather than previous CL, > effectively throwing previous CL away. > # resolveClassName() caches classes based on just the name > ** A class is not defined by name alone. Classes loaded by two different > unrelated CLs are different objects even if both extract the class from same > physical jar file. > ** because of (1), the cached class is not necessarily same as the class > that would be loaded based on 'current' CL > having different class objects for same class have many subtle side effects. > e.g. there would be two instances of static variables. > I think both should be fixed.. thought fixing one of them might be good > enough in many cases. I will add a patch. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira