Self-first classloading on the component and shared libraries is configured in the jbi.xml. For existing components, you will have to repackage them :( For xbean SU, you can use
<classpath inverse="true"> <hidden> xxx </hidden> <nonOverridable> xxx </nonOverridable> <location> xxx </location> </classpath> The inverse will use a self-first delegation. Hidden tags can be used to hide classes from the parent classloader. NonOverridable can be used to prevent classes from this classloader to be loaded. On 9/28/06, William Blackburn <[EMAIL PROTECTED]> wrote:
Guillaume, Thank you - I finally get it, you have also settled an argument between me and another dev here, who believed that the classloading scheme caused memory problems. With regard to self-first classloading and components in the lwcontainer - is self-first something that must be configured to use? If so, how? Thanks again, BJ On Sep 28, 2006, at 11:15 AM, Guillaume Nodet wrote: > 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
-- Cheers, Guillaume Nodet
