<quote> It shouldn't matter where the .jar's are placed for jetspeed to function, should it? Is this a Tocat problem?
The irony is that the line where it all starts going wrong, (!) NOTICE: Turbine: init() failed: java.lang.ClassNotFoundException: org.apache .jetspeed.services.resources.JetspeedResourceService refers to the class JetspeedResourceService, which is not even in a .jar at all, but resides in tomcat\webapps\jetspeed\WEB-INF\classes\org\apache\jetspeed\services\resourc es Can anybody shed some light on this? -Stijn <quote> Stijn, this is how classloaders work. The shared classloader can't look into the webapplication classloader to load the class. You put base classes of the turbine into the shared. Now the service broker must find a class and that class is at the lower level, right? So it can't look down into the web application it can only look up into its own parent. (Java2 parent delegation mechanism). So putting turbine into shared is not a good idea, as it goes through a set of configurations and need to keep the state of those configurations. I think that the only thing you can put in shared, is ecs, village and maybe some of the commons (but not commons-lang because of the same issue). Is this enough info or you need more detailed explanation? Dmitry
