Just put that on the wiki: http://goopen.org/confluence/display/SM/Classloaders
On 9/28/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
The classloading stuff is not related to any memory problem. There are several classloaders involved in ServiceMix: * the container class loader * shared library class loader: the parent is the container class loader * component class loader: parents are container class loader + any referenced SL class loader * service unit class loader: parent is the component class loader The container class loader contains: JRE + /conf + /lib/*.jar + /lib/optional/*.jar. The components are libraries class loaders are defined in the JBI spec and contain the jars referenced in the jbi descriptor. These class loaders can use a parent-first (default) or self-first delegation: when a class is loaded, the class loader will first ask its parent(s), or will first load the class from its referenced jars. The service unit class loader is not specified in the JBI spec, because the SU content is specific to each component. In ServiceMix, all xbean based SU may define their own classloader using the <classpath /> location. Let's say you deploy a pojo on the lwcontainer. When building the configuration, xbean need to find the class. It will ask the SU classloader to do so. So the component may be inside this classloader, or one of its parent (servicemix-lwcontainer, servicemix-shared and the container classloader). However, the component and SL classloaders are not easily modified (you need to repackage the artifact and redeploy it), so you can put this class in the SU or the container. If you put this class in the container, you will need to restart the container after having added the jar in the classpath, which is not what we want. So usually, we put it in the SU. The other benefit of using classloaders is that you can have isolated components. You could deploy two components (or SU) which use different version of the same library without any problems. This is not possible if you put all the dependencies in the container classpath. Self-first delegation. The common delegation mechanism for classloaders is to delegate to the parent first when loading a class. Thus, all classes defined in the container classloader are shared. But when a class reference another class (using an import statement in the java code for example), the referenced classes will be loaded by the same classloader. To avoid such problems, you can use a self-first delegation: classes will be loaded from the classloader, and if not found, it will ask its parent. Hope this helps. On 9/28/06, William Blackburn <[EMAIL PROTECTED]> wrote: > Sorry to ask this yet again, but every time I think I understand this > it turns out I don't. After reviewing these threads, I understand > that when deploying sa's containing su's consisting of servicemix > 'pojo' components to the lwcontainer, I must be careful to include > all the dependencies of my component within the su and referenced > using the classpath/location elements in my servicemix.xml file. I > think this is required to avoid loading all of the dependencies/libs > of servicemix as the classloader attempts to locate my referenced > classes, causing an overuse of memory - is this right? > > My other question is regarding the servicemix-specific classes/ > interfaces/dependencies that are referenced and/or implemented in the > pojo component itself, specifically : > javax.jbi.* > javax.management.* > org.apache.servicemix. > > should these be in the local classpath/location, or is it Ok to leave > them in the main servicemix deployment? > > Any further clarification is most welcome, and again, I appologize > for bein so obtuse on this subject. > > BJ > > > -- Cheers, Guillaume Nodet
-- Cheers, Guillaume Nodet
