Hi Simon, Comments inline.
> The POJO CI specs 1.1 makes a recommendation that, the thread context > > classloader of the thread used to invoke an > > operation of a Java POJO component implementation MUST be set as the > class > > loader of the contribution that contains > > the POJO implementation class. > > It seems to be more than a recommendation it seems to be a firm > requirement. > > > > > The POJO_10009 test case uses the below code to validate the same... > > > > ClassLoader tccl = > Thread.currentThread().getContextClassLoader(); > > ClassLoader loader = this.getClass().getClassLoader(); > > String result = " thread context classloader is correct"; > > if( loader != tccl ) result = " thread context classloader not > > correct"; > > I assume that this test currently fails? > Yes, this test case currently fails. > > > > > In the current Tuscany code, we use the ClassLoaderModelResolver which > > extends the URLClassLoader to load the classes. > > The ClassLoaderModelResolver internally sets its parent classloader as > TCCL. > > So the this.getClass().getClassLoader() > > returns ClassLoaderModelResolver instance always. > > The word "so" confuses me here. How are these two things related? > Surely this.getClass().getClassLoader() > returns ClassLoaderModelResolver when ClassLoaderModelResolver is used > to load the class regardless of what the classloaders parent is set > to. > I agree with you. My intention here is just to explain, what is happening in the current scenario. > > > > > In my opinion, the current Tuscany code looks valid as we would need a > > CustomClassLoader to load the classes > > from the contribution URL. In any case, the TCCL might not be able to > load > > the classes available from the contribution as the > > location is only known at runtime. So I believe the spec needs a change > in > > this case. > > The question seems to me... Do we set the contribution classloader > into TCCL before we call the component implementation? Maybe I'm > missing something. > I see that in the current code, we don't set a contribution classloader. The classLoader field in the ContributionImpl instance is always null. We also have a ContributionClassLoader class which never seems to be used. -- Thanks & Regards, Ramkumar Ramalingam
