Hi Ram Comments in line
> 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? > > 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. > > 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. Regards Simon
