You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by William Blackburn <wj...@mac.com> on 2006/09/28 19:07:26 UTC
Pojo components; the lwcontainer; classloading - more clarification please
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
Re: Pojo components; the lwcontainer; classloading - more clarification please
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <wj...@mac.com> 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 <gn...@gmail.com> 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 <wj...@mac.com> 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
Re: Pojo components; the lwcontainer; classloading - more clarification please
Posted by William Blackburn <wj...@mac.com>.
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 <gn...@gmail.com> 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 <wj...@mac.com> 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
Re: Pojo components; the lwcontainer; classloading - more clarification please
Posted by Guillaume Nodet <gn...@gmail.com>.
Just put that on the wiki:
http://goopen.org/confluence/display/SM/Classloaders
On 9/28/06, Guillaume Nodet <gn...@gmail.com> 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 <wj...@mac.com> 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
Re: Pojo components; the lwcontainer; classloading - more clarification please
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <wj...@mac.com> 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