On Wed, Dec 9, 2009 at 7:37 AM, Ramkumar R <[email protected]> wrote: > Hi Simon, > > Comments inline... > >> Not sure if this is important or not. In the implementation invoker we >> need to set TCCL to the contribution classloader that loaded the >> implementation class we are about to call. So how to get the >> contribution and it's classloader for the class we are about to call. >> The easy way is to get the classloader from the class and set that of >> course. I don't know if no changes have been made to make this work or >> that some changes have been made but that something was missed out. >> > > The issue seems to be resolved and the testcase passes, by setting the TCCL > to the > classloader that loaded the implementation class we are about to call. >
Is that really correct though for what section 10.3 in the spec is saying? The implementation class doesn't necessarily come from the containing contribution it could be an imported class, in which case according to JCI100010 and JCI100011 that would be using be a different class loader. > But this approach raises few questions in my mind as shown below... > > 1. In 1.x code base, we have been using the ContributionClassLoaderProvider > to set the > classloader for the contribution, but in 2.x not sure about the reason as > why decided to > get away with ContributionClassLoaderProvider. > I'm not sure if i understood this from your 1st email - isnt there a ClassLoaderModelResolver instance per contribution? And if so what happens if the ClassLoaderModelResolver instance is set as the TCCL? > 2. May be, I am not understanding the big picture as why the specs is so > keen in > doing so. What would be the disadvantage if we don't set the TCCL to the > contribution classloader. > I guess just so there's a consistent and predictable way to use class loaders and contribution resources across runtimes. ...ant
