> -----Original Message----- > From: Simon Nash [mailto:[email protected]] > Sent: Wednesday, December 07, 2011 9:50 PM > To: [email protected] > Subject: Re: Contributions and Runtime Classpath > > Simon Nash wrote: > > Millies, Sebastian wrote: > >> Hello there, > >> > >> I am having a class loading problem, and want to make sure that I > >> understand what a contribution is. > >> > >> My setup is as follows: At some point I want my SCA code to > >> dynamically load > >> > >> classes (customer-specific stuff provided by the customer at > >> deployment time).
[snip] > >> When I do > >> > Thread.currentThread().getContextClassLoader().loadClass(className) > >> > >> > >> > >> I get a ClassNotFoundException. What may I be overlooking? > >> > Tuscany uses contribution classloaders for loading code from > contributions. > > To get classes loaded by these classloaders, you need to use the SCA > > contribution import/export mechanism. Why does serviceInstance.getClass().getClassLoader() not give me the ContributionClassLoader that loaded the SCA service instance, but the Java application class loader? Isn't there some way for a service implementation to gain access to its contribution class loader at run time? Or is there a way to subclass the contribution class loader and load the extension through the subclass? For that, I'd need to be able to construct the contribution that I know the extension class is in from its location (given that I can at least know the jar file name, see below). > > It is possible to set things up so that code is loadable by a > contribution > > classloader as well as by the thread context classloader and/or the > system > > classloader that Java uses to start the application. However this > can > > cause problems with contribution import/export not working properly, > > so this setup isn't a good idea IMO. How would one set up things this way? Is there an example? And is it a fundamental problem that import/export does not work correctly in this case, or rather a bug that may be fixed? > > I prefer to set things up with the contribution classloaders separate > from > > the system classloader and thread context classloader. You can see > some > > examples of this setup in the travel sample--look at the Introducing > > scenario which bootstraps by loading three contributions in the > launcher, > > then hands control to one of them. All the classes in these > contributions > > aren't present on the Java system classpath and aren't loaded by the > > thread context classloader. Yes, that looks quite like my code in the original post. > > Can you say more about why you are trying to load contribution > classes > > using the thread context classloader? > > > > Simon > > > Some further thoughts on this: perhaps the issue is that you don't know > the Java packages of the customer classes and therefore can't list > these > classes in export and import statements. If so, I don't think you will > be able to use contributions to load these classes. However, if you do > know the package names then I think you should probably be able to make > this work using contributions if you set things up correctly. > > Simon That is exactly it. The customer can provide his own classes for certain tasks (enriching data, accessing proprietary data stores, exporting to Excel sheets, printing etc.). In some cases I may be able to prescribe at least a package name. In most cases both package name and class name will be unknown to me. The only thing I could prescribe would be the name of a jar-file, but I'd rather get along even without that. [Side note: I did try using the Java extension mechanism for bundling extensions (Class-Path entry for the jar in the manifest file of the SCA contribution), but that did not work either. If I understand you correctly, this is not even supposed to be supported by Tuscany, because it would through the context class loader as well.] -- Sebastian IDS Scheer Consulting GmbH Geschäftsführer/Managing Directors: Kamyar Niroumand, Ivo Totev Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, Germany - Registergericht/Commercial register: Saarbrücken HRB 19681 http://www.softwareag.com
