You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Amila Suriarachchi <am...@gmail.com> on 2009/05/15 16:14:54 UTC
[Axis2] Child first class loading
hi all,
Currently Axis2 follows the parent first class loading for service and
module loading.
The reason for this is it uses DeploymentClassLoader loader which is
extended from the ClassLoader class.
The loadClass method of the ClassLoader class looks like this.
protected synchronized Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// First, check if the class has already been loaded
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
// If still not found, then invoke findClass in order
// to find the class.
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
it first check for parent class loader classes and then for its classes. So
we can add child first class loading simply reversing this order in a
override loadClass method as follows.
protected synchronized Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException {
Class c = findLoadedClass(name);
if (c == null) {
try {
c = findClass(name);
} catch (Exception e) {
c = super.loadClass(name, resolve);
}
}
return c;
}
I have attach the patch here[1].
I tested this with a sample service and it worked fine. Will do some tests
with the modules as well.
I think this should be the default behaviour to axis2 since it allows people
to use their own classes at the service/module level.
Any thoughts?
thanks,
Amila.
[1] https://issues.apache.org/jira/browse/AXIS2-4349
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2] Child first class loading
Posted by Andreas Veithen <an...@gmail.com>.
Tomcat is indeed a better analogy and there are actually two other key
points that Tomcat (or the servlet spec) uses to avoid problems
related to parent-last class loading:
1. The parent class loader in Tomcat only exposes the classes that are
strictly necessary. This means that in general you actually don't care
about parent-first or parent-last (except for the notoriously
difficult logging setup).
2. Classes that are referenced in the API exposed by the container are
never loaded from the child class loader. For a servlet container this
is fairly easy because all these classes are either part of the JRE or
the servlet and JSP API. This is why the servlet specs say that
classes from javax.servlet must never be loaded from WEB-INF/classes
or WEB-INF/lib. I don't think it's possible to easily establish a
similar list of "prohibited" packages for Axis2.
Andreas
On Mon, May 18, 2009 at 17:06, Jason Fager <ja...@riskmetrics.com> wrote:
> A better analogy for this would be Tomcat, wouldn't it?
>
> http://tomcat.apache.org/tomcat-5.5-doc/printer/class-loader-howto.html
>
> I think the key point here is that simple "child-first/parent-last" isn't
> quite right: Bootstrap and System (in that order) should come first, so
> that critical classes can't be overridden and so that the user has a chance
> to change things at startup by setting the CLASSPATH variable.
>
> - Jason
>
>
>
>
>
>> I think that if somebody places a class in a MAR/AAR, his expectation
>> is that the particular class in concern will be loaded from the
>> MAR/AAR. If he places that class somewhere up in the classloader
>> hierarchy (and not in the MAR/AAR), his expectation is that the class
>> will be loaded from the parent. So it is basically up to the user to
>> decide where to place the class. So I think having child first
>> classloading should be OK, and that we do not require a parameter to
>> control this. If a user is placing the class in the MAR/AAR as well as
>> higher up in the hierarchy, it may indicate bad design on the user's
>> part, which he needs to be fixed anyway.
>>
>> Taking OSGi as an analogy, one bundle may get wired to one other
>> bundle which exports a particular package, even though there are
>> multiple bundles exporting the same package (different versions of it
>> possibly), which forces the user to think through the wiring, which is
>> a good thing.
>>
>> Azeez
>>
>> On Fri, May 15, 2009 at 8:05 PM, Andreas Veithen
>> <an...@gmail.com> wrote:
>>> +1 for allowing parent last class loading, but -1 for making it the
>>> default. The reason is that I once worked on a larger project where we
>>> had to use parent last class loading (because we needed a newer
>>> version of some library that was exposed by the app server), and from
>>> that experience I know that using this policy leads to issues that are
>>> very hard to debug. If we make it the default, I expect that it will
>>> break many existing services that users have built.
>>>
>>> We should really make it configurable, with the parent first policy as
>>> default. The interesting question is at what level this should be
>>> configured. I would say that it should be an option in
>>> service.xml/module.xml, but that makes it probably a bit more
>>> difficult to implement.
>>>
>>> Andreas
>>>
>>> On Fri, May 15, 2009 at 16:14, Amila Suriarachchi
>>> <am...@gmail.com> wrote:
>>>> hi all,
>>>>
>>>> Currently Axis2 follows the parent first class loading for service and
>>>> module loading.
>>>>
>>>> The reason for this is it uses DeploymentClassLoader loader which is
>>>> extended from the ClassLoader class.
>>>>
>>>> The loadClass method of the ClassLoader class looks like this.
>>>>
>>>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>>>> throws ClassNotFoundException
>>>> {
>>>> // First, check if the class has already been loaded
>>>> Class c = findLoadedClass(name);
>>>> if (c == null) {
>>>> try {
>>>> if (parent != null) {
>>>> c = parent.loadClass(name, false);
>>>> } else {
>>>> c = findBootstrapClass0(name);
>>>> }
>>>> } catch (ClassNotFoundException e) {
>>>> // If still not found, then invoke findClass in order
>>>> // to find the class.
>>>> c = findClass(name);
>>>> }
>>>> }
>>>> if (resolve) {
>>>> resolveClass(c);
>>>> }
>>>> return c;
>>>> }
>>>>
>>>> it first check for parent class loader classes and then for its classes. So
>>>> we can add child first class loading simply reversing this order in a
>>>> override loadClass method as follows.
>>>>
>>>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>>>> throws ClassNotFoundException {
>>>>
>>>> Class c = findLoadedClass(name);
>>>> if (c == null) {
>>>> try {
>>>> c = findClass(name);
>>>> } catch (Exception e) {
>>>> c = super.loadClass(name, resolve);
>>>> }
>>>> }
>>>> return c;
>>>> }
>>>>
>>>> I have attach the patch here[1].
>>>>
>>>> I tested this with a sample service and it worked fine. Will do some tests
>>>> with the modules as well.
>>>>
>>>> I think this should be the default behaviour to axis2 since it allows people
>>>> to use their own classes at the service/module level.
>>>>
>>>> Any thoughts?
>>>>
>>>> thanks,
>>>> Amila.
>>>>
>>>>
>>>> [1] https://issues.apache.org/jira/browse/AXIS2-4349
>>>>
>>>>
>>>>
>>>> --
>>>> Amila Suriarachchi
>>>> WSO2 Inc.
>>>> blog: http://amilachinthaka.blogspot.com/
>>>>
>>>
>>
>>
>>
>> --
>> Thanks
>> Afkham Azeez
>>
>> Blog: http://afkham.org
>> Developer Portal: http://www.wso2.org
>> WSAS Blog: http://wso2wsas.blogspot.com
>> Company: http://wso2.com
>> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
>
Re: [Axis2] Child first class loading
Posted by Amila Suriarachchi <am...@gmail.com>.
On Mon, May 18, 2009 at 8:36 PM, Jason Fager <ja...@riskmetrics.com>wrote:
> A better analogy for this would be Tomcat, wouldn't it?
>
> http://tomcat.apache.org/tomcat-5.5-doc/printer/class-loader-howto.html
>
> I think the key point here is that simple "child-first/parent-last" isn't
> quite right: Bootstrap and System (in that order) should come first, so
> that critical classes can't be overridden and so that the user has a chance
> to change things at startup by setting the CLASSPATH variable.
the child first class loading only effect at the service or module level.
Although it is a possibility I think it is a rear case some one need to
change the axis2-kernal
class in his service or module. On the other hand if some one really needs
it, why we need to stop it.
I agree with you that Tomcat has a much better class loading hierarchy. But
IMHO in this stage we should not try to make it complicated specially with
class loading.
thanks,
Amila.
>
>
> - Jason
>
>
>
>
>
> > I think that if somebody places a class in a MAR/AAR, his expectation
> > is that the particular class in concern will be loaded from the
> > MAR/AAR. If he places that class somewhere up in the classloader
> > hierarchy (and not in the MAR/AAR), his expectation is that the class
> > will be loaded from the parent. So it is basically up to the user to
> > decide where to place the class. So I think having child first
> > classloading should be OK, and that we do not require a parameter to
> > control this. If a user is placing the class in the MAR/AAR as well as
> > higher up in the hierarchy, it may indicate bad design on the user's
> > part, which he needs to be fixed anyway.
> >
> > Taking OSGi as an analogy, one bundle may get wired to one other
> > bundle which exports a particular package, even though there are
> > multiple bundles exporting the same package (different versions of it
> > possibly), which forces the user to think through the wiring, which is
> > a good thing.
> >
> > Azeez
> >
> > On Fri, May 15, 2009 at 8:05 PM, Andreas Veithen
> > <an...@gmail.com> wrote:
> >> +1 for allowing parent last class loading, but -1 for making it the
> >> default. The reason is that I once worked on a larger project where we
> >> had to use parent last class loading (because we needed a newer
> >> version of some library that was exposed by the app server), and from
> >> that experience I know that using this policy leads to issues that are
> >> very hard to debug. If we make it the default, I expect that it will
> >> break many existing services that users have built.
> >>
> >> We should really make it configurable, with the parent first policy as
> >> default. The interesting question is at what level this should be
> >> configured. I would say that it should be an option in
> >> service.xml/module.xml, but that makes it probably a bit more
> >> difficult to implement.
> >>
> >> Andreas
> >>
> >> On Fri, May 15, 2009 at 16:14, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >>> hi all,
> >>>
> >>> Currently Axis2 follows the parent first class loading for service and
> >>> module loading.
> >>>
> >>> The reason for this is it uses DeploymentClassLoader loader which is
> >>> extended from the ClassLoader class.
> >>>
> >>> The loadClass method of the ClassLoader class looks like this.
> >>>
> >>> protected synchronized Class<?> loadClass(String name, boolean resolve)
> >>> throws ClassNotFoundException
> >>> {
> >>> // First, check if the class has already been loaded
> >>> Class c = findLoadedClass(name);
> >>> if (c == null) {
> >>> try {
> >>> if (parent != null) {
> >>> c = parent.loadClass(name, false);
> >>> } else {
> >>> c = findBootstrapClass0(name);
> >>> }
> >>> } catch (ClassNotFoundException e) {
> >>> // If still not found, then invoke findClass in order
> >>> // to find the class.
> >>> c = findClass(name);
> >>> }
> >>> }
> >>> if (resolve) {
> >>> resolveClass(c);
> >>> }
> >>> return c;
> >>> }
> >>>
> >>> it first check for parent class loader classes and then for its
> classes. So
> >>> we can add child first class loading simply reversing this order in a
> >>> override loadClass method as follows.
> >>>
> >>> protected synchronized Class<?> loadClass(String name, boolean resolve)
> >>> throws ClassNotFoundException {
> >>>
> >>> Class c = findLoadedClass(name);
> >>> if (c == null) {
> >>> try {
> >>> c = findClass(name);
> >>> } catch (Exception e) {
> >>> c = super.loadClass(name, resolve);
> >>> }
> >>> }
> >>> return c;
> >>> }
> >>>
> >>> I have attach the patch here[1].
> >>>
> >>> I tested this with a sample service and it worked fine. Will do some
> tests
> >>> with the modules as well.
> >>>
> >>> I think this should be the default behaviour to axis2 since it allows
> people
> >>> to use their own classes at the service/module level.
> >>>
> >>> Any thoughts?
> >>>
> >>> thanks,
> >>> Amila.
> >>>
> >>>
> >>> [1] https://issues.apache.org/jira/browse/AXIS2-4349
> >>>
> >>>
> >>>
> >>> --
> >>> Amila Suriarachchi
> >>> WSO2 Inc.
> >>> blog: http://amilachinthaka.blogspot.com/
> >>>
> >>
> >
> >
> >
> > --
> > Thanks
> > Afkham Azeez
> >
> > Blog: http://afkham.org
> > Developer Portal: http://www.wso2.org
> > WSAS Blog: http://wso2wsas.blogspot.com
> > Company: http://wso2.com
> > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2] Child first class loading
Posted by Andreas Veithen <an...@gmail.com>.
Afkham,
The problems related to parent-last class loading are in general not
caused by design issues, but by duplicate dependencies. Consider a
simple example: in the service implementation, the developer uses some
framework that depends on activation.jar. He downloads the binary
distribution and copies all the dependencies (including
activation.jar) into the lib folder of the AAR. This works perfectly
with parent-first. If we switch to parent-last and the service
implementation happens to use DataHandler to represent base64 values,
this will result in ClassCastExceptions (or LinkageErrors?) and the
service will be broken.
Andreas
On Mon, May 18, 2009 at 21:14, Afkham Azeez <af...@gmail.com> wrote:
> On Tue, May 19, 2009 at 12:24 AM, Andreas Veithen
> <an...@gmail.com> wrote:
>> On Mon, May 18, 2009 at 15:46, Afkham Azeez <af...@gmail.com> wrote:
>>> I think that if somebody places a class in a MAR/AAR, his expectation
>>> is that the particular class in concern will be loaded from the
>>> MAR/AAR. If he places that class somewhere up in the classloader
>>> hierarchy (and not in the MAR/AAR), his expectation is that the class
>>> will be loaded from the parent. So it is basically up to the user to
>>> decide where to place the class. So I think having child first
>>> classloading should be OK, and that we do not require a parameter to
>>> control this. If a user is placing the class in the MAR/AAR as well as
>>> higher up in the hierarchy, it may indicate bad design on the user's
>>> part, which he needs to be fixed anyway.
>>
>> From a theoretical point of view, that might be a valid argument, but
>> the reality is that very likely many users have services that will
>> break
> So you are suggesting that many Axis2 users have systems where classes
> & packages are duplicated in multiple places? (within the AAR/MAR as
> well as say WEB-INF/lib?) If that is the case, they need to be told
> that this is not the correct approach.
>
> if we change the default class loading policy. Since the average
>> developer is not aware of the subtleties of class loading, they will
>> blame Axis2 for that. Why would we take this risk if we can avoid it
>> by using a simple switch in axis2.xml (or module.xml/service.xml)?
>>
>>> Taking OSGi as an analogy, one bundle may get wired to one other
>>> bundle which exports a particular package, even though there are
>>> multiple bundles exporting the same package (different versions of it
>>> possibly), which forces the user to think through the wiring, which is
>>> a good thing.
>>
>> OSGi is not a valid analogy here because it has the right mechanisms
>> to avoid the problems you see in containers with parent-last class
>> loading (and a parent class loader that exposes lots of classes).
>>
> I took the OSGi analogy to show that a bundle gets wired to another
> bundle which exports a package (split packages excluded, since that is
> not generally recommended). If the user is placing jars with the same
> packages at different levels of the class loader hierarchy, thereby
> picking up classes from different jars along the line, this seems
> pretty messed up, and indicates an ill-thought out design on the
> user's part.
>
>>> Azeez
>>>
>>> On Fri, May 15, 2009 at 8:05 PM, Andreas Veithen
>>> <an...@gmail.com> wrote:
>>>> +1 for allowing parent last class loading, but -1 for making it the
>>>> default. The reason is that I once worked on a larger project where we
>>>> had to use parent last class loading (because we needed a newer
>>>> version of some library that was exposed by the app server), and from
>>>> that experience I know that using this policy leads to issues that are
>>>> very hard to debug. If we make it the default, I expect that it will
>>>> break many existing services that users have built.
>>>>
>>>> We should really make it configurable, with the parent first policy as
>>>> default. The interesting question is at what level this should be
>>>> configured. I would say that it should be an option in
>>>> service.xml/module.xml, but that makes it probably a bit more
>>>> difficult to implement.
>>>>
>>>> Andreas
>>>>
>>>> On Fri, May 15, 2009 at 16:14, Amila Suriarachchi
>>>> <am...@gmail.com> wrote:
>>>>> hi all,
>>>>>
>>>>> Currently Axis2 follows the parent first class loading for service and
>>>>> module loading.
>>>>>
>>>>> The reason for this is it uses DeploymentClassLoader loader which is
>>>>> extended from the ClassLoader class.
>>>>>
>>>>> The loadClass method of the ClassLoader class looks like this.
>>>>>
>>>>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>>>>> throws ClassNotFoundException
>>>>> {
>>>>> // First, check if the class has already been loaded
>>>>> Class c = findLoadedClass(name);
>>>>> if (c == null) {
>>>>> try {
>>>>> if (parent != null) {
>>>>> c = parent.loadClass(name, false);
>>>>> } else {
>>>>> c = findBootstrapClass0(name);
>>>>> }
>>>>> } catch (ClassNotFoundException e) {
>>>>> // If still not found, then invoke findClass in order
>>>>> // to find the class.
>>>>> c = findClass(name);
>>>>> }
>>>>> }
>>>>> if (resolve) {
>>>>> resolveClass(c);
>>>>> }
>>>>> return c;
>>>>> }
>>>>>
>>>>> it first check for parent class loader classes and then for its classes. So
>>>>> we can add child first class loading simply reversing this order in a
>>>>> override loadClass method as follows.
>>>>>
>>>>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>>>>> throws ClassNotFoundException {
>>>>>
>>>>> Class c = findLoadedClass(name);
>>>>> if (c == null) {
>>>>> try {
>>>>> c = findClass(name);
>>>>> } catch (Exception e) {
>>>>> c = super.loadClass(name, resolve);
>>>>> }
>>>>> }
>>>>> return c;
>>>>> }
>>>>>
>>>>> I have attach the patch here[1].
>>>>>
>>>>> I tested this with a sample service and it worked fine. Will do some tests
>>>>> with the modules as well.
>>>>>
>>>>> I think this should be the default behaviour to axis2 since it allows people
>>>>> to use their own classes at the service/module level.
>>>>>
>>>>> Any thoughts?
>>>>>
>>>>> thanks,
>>>>> Amila.
>>>>>
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/AXIS2-4349
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Amila Suriarachchi
>>>>> WSO2 Inc.
>>>>> blog: http://amilachinthaka.blogspot.com/
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks
>>> Afkham Azeez
>>>
>>> Blog: http://afkham.org
>>> Developer Portal: http://www.wso2.org
>>> WSAS Blog: http://wso2wsas.blogspot.com
>>> Company: http://wso2.com
>>> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>>>
>>
>
>
>
> --
> Thanks
> Afkham Azeez
>
> Blog: http://afkham.org
> Developer Portal: http://www.wso2.org
> WSAS Blog: http://wso2wsas.blogspot.com
> Company: http://wso2.com
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
Re: [Axis2] Child first class loading
Posted by Afkham Azeez <af...@gmail.com>.
On Tue, May 19, 2009 at 12:24 AM, Andreas Veithen
<an...@gmail.com> wrote:
> On Mon, May 18, 2009 at 15:46, Afkham Azeez <af...@gmail.com> wrote:
>> I think that if somebody places a class in a MAR/AAR, his expectation
>> is that the particular class in concern will be loaded from the
>> MAR/AAR. If he places that class somewhere up in the classloader
>> hierarchy (and not in the MAR/AAR), his expectation is that the class
>> will be loaded from the parent. So it is basically up to the user to
>> decide where to place the class. So I think having child first
>> classloading should be OK, and that we do not require a parameter to
>> control this. If a user is placing the class in the MAR/AAR as well as
>> higher up in the hierarchy, it may indicate bad design on the user's
>> part, which he needs to be fixed anyway.
>
> From a theoretical point of view, that might be a valid argument, but
> the reality is that very likely many users have services that will
> break
So you are suggesting that many Axis2 users have systems where classes
& packages are duplicated in multiple places? (within the AAR/MAR as
well as say WEB-INF/lib?) If that is the case, they need to be told
that this is not the correct approach.
if we change the default class loading policy. Since the average
> developer is not aware of the subtleties of class loading, they will
> blame Axis2 for that. Why would we take this risk if we can avoid it
> by using a simple switch in axis2.xml (or module.xml/service.xml)?
>
>> Taking OSGi as an analogy, one bundle may get wired to one other
>> bundle which exports a particular package, even though there are
>> multiple bundles exporting the same package (different versions of it
>> possibly), which forces the user to think through the wiring, which is
>> a good thing.
>
> OSGi is not a valid analogy here because it has the right mechanisms
> to avoid the problems you see in containers with parent-last class
> loading (and a parent class loader that exposes lots of classes).
>
I took the OSGi analogy to show that a bundle gets wired to another
bundle which exports a package (split packages excluded, since that is
not generally recommended). If the user is placing jars with the same
packages at different levels of the class loader hierarchy, thereby
picking up classes from different jars along the line, this seems
pretty messed up, and indicates an ill-thought out design on the
user's part.
>> Azeez
>>
>> On Fri, May 15, 2009 at 8:05 PM, Andreas Veithen
>> <an...@gmail.com> wrote:
>>> +1 for allowing parent last class loading, but -1 for making it the
>>> default. The reason is that I once worked on a larger project where we
>>> had to use parent last class loading (because we needed a newer
>>> version of some library that was exposed by the app server), and from
>>> that experience I know that using this policy leads to issues that are
>>> very hard to debug. If we make it the default, I expect that it will
>>> break many existing services that users have built.
>>>
>>> We should really make it configurable, with the parent first policy as
>>> default. The interesting question is at what level this should be
>>> configured. I would say that it should be an option in
>>> service.xml/module.xml, but that makes it probably a bit more
>>> difficult to implement.
>>>
>>> Andreas
>>>
>>> On Fri, May 15, 2009 at 16:14, Amila Suriarachchi
>>> <am...@gmail.com> wrote:
>>>> hi all,
>>>>
>>>> Currently Axis2 follows the parent first class loading for service and
>>>> module loading.
>>>>
>>>> The reason for this is it uses DeploymentClassLoader loader which is
>>>> extended from the ClassLoader class.
>>>>
>>>> The loadClass method of the ClassLoader class looks like this.
>>>>
>>>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>>>> throws ClassNotFoundException
>>>> {
>>>> // First, check if the class has already been loaded
>>>> Class c = findLoadedClass(name);
>>>> if (c == null) {
>>>> try {
>>>> if (parent != null) {
>>>> c = parent.loadClass(name, false);
>>>> } else {
>>>> c = findBootstrapClass0(name);
>>>> }
>>>> } catch (ClassNotFoundException e) {
>>>> // If still not found, then invoke findClass in order
>>>> // to find the class.
>>>> c = findClass(name);
>>>> }
>>>> }
>>>> if (resolve) {
>>>> resolveClass(c);
>>>> }
>>>> return c;
>>>> }
>>>>
>>>> it first check for parent class loader classes and then for its classes. So
>>>> we can add child first class loading simply reversing this order in a
>>>> override loadClass method as follows.
>>>>
>>>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>>>> throws ClassNotFoundException {
>>>>
>>>> Class c = findLoadedClass(name);
>>>> if (c == null) {
>>>> try {
>>>> c = findClass(name);
>>>> } catch (Exception e) {
>>>> c = super.loadClass(name, resolve);
>>>> }
>>>> }
>>>> return c;
>>>> }
>>>>
>>>> I have attach the patch here[1].
>>>>
>>>> I tested this with a sample service and it worked fine. Will do some tests
>>>> with the modules as well.
>>>>
>>>> I think this should be the default behaviour to axis2 since it allows people
>>>> to use their own classes at the service/module level.
>>>>
>>>> Any thoughts?
>>>>
>>>> thanks,
>>>> Amila.
>>>>
>>>>
>>>> [1] https://issues.apache.org/jira/browse/AXIS2-4349
>>>>
>>>>
>>>>
>>>> --
>>>> Amila Suriarachchi
>>>> WSO2 Inc.
>>>> blog: http://amilachinthaka.blogspot.com/
>>>>
>>>
>>
>>
>>
>> --
>> Thanks
>> Afkham Azeez
>>
>> Blog: http://afkham.org
>> Developer Portal: http://www.wso2.org
>> WSAS Blog: http://wso2wsas.blogspot.com
>> Company: http://wso2.com
>> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>>
>
--
Thanks
Afkham Azeez
Blog: http://afkham.org
Developer Portal: http://www.wso2.org
WSAS Blog: http://wso2wsas.blogspot.com
Company: http://wso2.com
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Child first class loading
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, May 18, 2009 at 15:46, Afkham Azeez <af...@gmail.com> wrote:
> I think that if somebody places a class in a MAR/AAR, his expectation
> is that the particular class in concern will be loaded from the
> MAR/AAR. If he places that class somewhere up in the classloader
> hierarchy (and not in the MAR/AAR), his expectation is that the class
> will be loaded from the parent. So it is basically up to the user to
> decide where to place the class. So I think having child first
> classloading should be OK, and that we do not require a parameter to
> control this. If a user is placing the class in the MAR/AAR as well as
> higher up in the hierarchy, it may indicate bad design on the user's
> part, which he needs to be fixed anyway.
>From a theoretical point of view, that might be a valid argument, but
the reality is that very likely many users have services that will
break if we change the default class loading policy. Since the average
developer is not aware of the subtleties of class loading, they will
blame Axis2 for that. Why would we take this risk if we can avoid it
by using a simple switch in axis2.xml (or module.xml/service.xml)?
> Taking OSGi as an analogy, one bundle may get wired to one other
> bundle which exports a particular package, even though there are
> multiple bundles exporting the same package (different versions of it
> possibly), which forces the user to think through the wiring, which is
> a good thing.
OSGi is not a valid analogy here because it has the right mechanisms
to avoid the problems you see in containers with parent-last class
loading (and a parent class loader that exposes lots of classes).
> Azeez
>
> On Fri, May 15, 2009 at 8:05 PM, Andreas Veithen
> <an...@gmail.com> wrote:
>> +1 for allowing parent last class loading, but -1 for making it the
>> default. The reason is that I once worked on a larger project where we
>> had to use parent last class loading (because we needed a newer
>> version of some library that was exposed by the app server), and from
>> that experience I know that using this policy leads to issues that are
>> very hard to debug. If we make it the default, I expect that it will
>> break many existing services that users have built.
>>
>> We should really make it configurable, with the parent first policy as
>> default. The interesting question is at what level this should be
>> configured. I would say that it should be an option in
>> service.xml/module.xml, but that makes it probably a bit more
>> difficult to implement.
>>
>> Andreas
>>
>> On Fri, May 15, 2009 at 16:14, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>>> hi all,
>>>
>>> Currently Axis2 follows the parent first class loading for service and
>>> module loading.
>>>
>>> The reason for this is it uses DeploymentClassLoader loader which is
>>> extended from the ClassLoader class.
>>>
>>> The loadClass method of the ClassLoader class looks like this.
>>>
>>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>>> throws ClassNotFoundException
>>> {
>>> // First, check if the class has already been loaded
>>> Class c = findLoadedClass(name);
>>> if (c == null) {
>>> try {
>>> if (parent != null) {
>>> c = parent.loadClass(name, false);
>>> } else {
>>> c = findBootstrapClass0(name);
>>> }
>>> } catch (ClassNotFoundException e) {
>>> // If still not found, then invoke findClass in order
>>> // to find the class.
>>> c = findClass(name);
>>> }
>>> }
>>> if (resolve) {
>>> resolveClass(c);
>>> }
>>> return c;
>>> }
>>>
>>> it first check for parent class loader classes and then for its classes. So
>>> we can add child first class loading simply reversing this order in a
>>> override loadClass method as follows.
>>>
>>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>>> throws ClassNotFoundException {
>>>
>>> Class c = findLoadedClass(name);
>>> if (c == null) {
>>> try {
>>> c = findClass(name);
>>> } catch (Exception e) {
>>> c = super.loadClass(name, resolve);
>>> }
>>> }
>>> return c;
>>> }
>>>
>>> I have attach the patch here[1].
>>>
>>> I tested this with a sample service and it worked fine. Will do some tests
>>> with the modules as well.
>>>
>>> I think this should be the default behaviour to axis2 since it allows people
>>> to use their own classes at the service/module level.
>>>
>>> Any thoughts?
>>>
>>> thanks,
>>> Amila.
>>>
>>>
>>> [1] https://issues.apache.org/jira/browse/AXIS2-4349
>>>
>>>
>>>
>>> --
>>> Amila Suriarachchi
>>> WSO2 Inc.
>>> blog: http://amilachinthaka.blogspot.com/
>>>
>>
>
>
>
> --
> Thanks
> Afkham Azeez
>
> Blog: http://afkham.org
> Developer Portal: http://www.wso2.org
> WSAS Blog: http://wso2wsas.blogspot.com
> Company: http://wso2.com
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
>
Re: [Axis2] Child first class loading
Posted by Jason Fager <ja...@riskmetrics.com>.
A better analogy for this would be Tomcat, wouldn't it?
http://tomcat.apache.org/tomcat-5.5-doc/printer/class-loader-howto.html
I think the key point here is that simple "child-first/parent-last" isn't
quite right: Bootstrap and System (in that order) should come first, so
that critical classes can't be overridden and so that the user has a chance
to change things at startup by setting the CLASSPATH variable.
- Jason
> I think that if somebody places a class in a MAR/AAR, his expectation
> is that the particular class in concern will be loaded from the
> MAR/AAR. If he places that class somewhere up in the classloader
> hierarchy (and not in the MAR/AAR), his expectation is that the class
> will be loaded from the parent. So it is basically up to the user to
> decide where to place the class. So I think having child first
> classloading should be OK, and that we do not require a parameter to
> control this. If a user is placing the class in the MAR/AAR as well as
> higher up in the hierarchy, it may indicate bad design on the user's
> part, which he needs to be fixed anyway.
>
> Taking OSGi as an analogy, one bundle may get wired to one other
> bundle which exports a particular package, even though there are
> multiple bundles exporting the same package (different versions of it
> possibly), which forces the user to think through the wiring, which is
> a good thing.
>
> Azeez
>
> On Fri, May 15, 2009 at 8:05 PM, Andreas Veithen
> <an...@gmail.com> wrote:
>> +1 for allowing parent last class loading, but -1 for making it the
>> default. The reason is that I once worked on a larger project where we
>> had to use parent last class loading (because we needed a newer
>> version of some library that was exposed by the app server), and from
>> that experience I know that using this policy leads to issues that are
>> very hard to debug. If we make it the default, I expect that it will
>> break many existing services that users have built.
>>
>> We should really make it configurable, with the parent first policy as
>> default. The interesting question is at what level this should be
>> configured. I would say that it should be an option in
>> service.xml/module.xml, but that makes it probably a bit more
>> difficult to implement.
>>
>> Andreas
>>
>> On Fri, May 15, 2009 at 16:14, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>>> hi all,
>>>
>>> Currently Axis2 follows the parent first class loading for service and
>>> module loading.
>>>
>>> The reason for this is it uses DeploymentClassLoader loader which is
>>> extended from the ClassLoader class.
>>>
>>> The loadClass method of the ClassLoader class looks like this.
>>>
>>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>>> throws ClassNotFoundException
>>> {
>>> // First, check if the class has already been loaded
>>> Class c = findLoadedClass(name);
>>> if (c == null) {
>>> try {
>>> if (parent != null) {
>>> c = parent.loadClass(name, false);
>>> } else {
>>> c = findBootstrapClass0(name);
>>> }
>>> } catch (ClassNotFoundException e) {
>>> // If still not found, then invoke findClass in order
>>> // to find the class.
>>> c = findClass(name);
>>> }
>>> }
>>> if (resolve) {
>>> resolveClass(c);
>>> }
>>> return c;
>>> }
>>>
>>> it first check for parent class loader classes and then for its classes. So
>>> we can add child first class loading simply reversing this order in a
>>> override loadClass method as follows.
>>>
>>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>>> throws ClassNotFoundException {
>>>
>>> Class c = findLoadedClass(name);
>>> if (c == null) {
>>> try {
>>> c = findClass(name);
>>> } catch (Exception e) {
>>> c = super.loadClass(name, resolve);
>>> }
>>> }
>>> return c;
>>> }
>>>
>>> I have attach the patch here[1].
>>>
>>> I tested this with a sample service and it worked fine. Will do some tests
>>> with the modules as well.
>>>
>>> I think this should be the default behaviour to axis2 since it allows people
>>> to use their own classes at the service/module level.
>>>
>>> Any thoughts?
>>>
>>> thanks,
>>> Amila.
>>>
>>>
>>> [1] https://issues.apache.org/jira/browse/AXIS2-4349
>>>
>>>
>>>
>>> --
>>> Amila Suriarachchi
>>> WSO2 Inc.
>>> blog: http://amilachinthaka.blogspot.com/
>>>
>>
>
>
>
> --
> Thanks
> Afkham Azeez
>
> Blog: http://afkham.org
> Developer Portal: http://www.wso2.org
> WSAS Blog: http://wso2wsas.blogspot.com
> Company: http://wso2.com
> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Child first class loading
Posted by Afkham Azeez <af...@gmail.com>.
I think that if somebody places a class in a MAR/AAR, his expectation
is that the particular class in concern will be loaded from the
MAR/AAR. If he places that class somewhere up in the classloader
hierarchy (and not in the MAR/AAR), his expectation is that the class
will be loaded from the parent. So it is basically up to the user to
decide where to place the class. So I think having child first
classloading should be OK, and that we do not require a parameter to
control this. If a user is placing the class in the MAR/AAR as well as
higher up in the hierarchy, it may indicate bad design on the user's
part, which he needs to be fixed anyway.
Taking OSGi as an analogy, one bundle may get wired to one other
bundle which exports a particular package, even though there are
multiple bundles exporting the same package (different versions of it
possibly), which forces the user to think through the wiring, which is
a good thing.
Azeez
On Fri, May 15, 2009 at 8:05 PM, Andreas Veithen
<an...@gmail.com> wrote:
> +1 for allowing parent last class loading, but -1 for making it the
> default. The reason is that I once worked on a larger project where we
> had to use parent last class loading (because we needed a newer
> version of some library that was exposed by the app server), and from
> that experience I know that using this policy leads to issues that are
> very hard to debug. If we make it the default, I expect that it will
> break many existing services that users have built.
>
> We should really make it configurable, with the parent first policy as
> default. The interesting question is at what level this should be
> configured. I would say that it should be an option in
> service.xml/module.xml, but that makes it probably a bit more
> difficult to implement.
>
> Andreas
>
> On Fri, May 15, 2009 at 16:14, Amila Suriarachchi
> <am...@gmail.com> wrote:
>> hi all,
>>
>> Currently Axis2 follows the parent first class loading for service and
>> module loading.
>>
>> The reason for this is it uses DeploymentClassLoader loader which is
>> extended from the ClassLoader class.
>>
>> The loadClass method of the ClassLoader class looks like this.
>>
>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>> throws ClassNotFoundException
>> {
>> // First, check if the class has already been loaded
>> Class c = findLoadedClass(name);
>> if (c == null) {
>> try {
>> if (parent != null) {
>> c = parent.loadClass(name, false);
>> } else {
>> c = findBootstrapClass0(name);
>> }
>> } catch (ClassNotFoundException e) {
>> // If still not found, then invoke findClass in order
>> // to find the class.
>> c = findClass(name);
>> }
>> }
>> if (resolve) {
>> resolveClass(c);
>> }
>> return c;
>> }
>>
>> it first check for parent class loader classes and then for its classes. So
>> we can add child first class loading simply reversing this order in a
>> override loadClass method as follows.
>>
>> protected synchronized Class<?> loadClass(String name, boolean resolve)
>> throws ClassNotFoundException {
>>
>> Class c = findLoadedClass(name);
>> if (c == null) {
>> try {
>> c = findClass(name);
>> } catch (Exception e) {
>> c = super.loadClass(name, resolve);
>> }
>> }
>> return c;
>> }
>>
>> I have attach the patch here[1].
>>
>> I tested this with a sample service and it worked fine. Will do some tests
>> with the modules as well.
>>
>> I think this should be the default behaviour to axis2 since it allows people
>> to use their own classes at the service/module level.
>>
>> Any thoughts?
>>
>> thanks,
>> Amila.
>>
>>
>> [1] https://issues.apache.org/jira/browse/AXIS2-4349
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
--
Thanks
Afkham Azeez
Blog: http://afkham.org
Developer Portal: http://www.wso2.org
WSAS Blog: http://wso2wsas.blogspot.com
Company: http://wso2.com
GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760
Re: [Axis2] Child first class loading
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, May 15, 2009 at 8:05 PM, Andreas Veithen
<an...@gmail.com>wrote:
> +1 for allowing parent last class loading, but -1 for making it the
> default. The reason is that I once worked on a larger project where we
> had to use parent last class loading (because we needed a newer
> version of some library that was exposed by the app server), and from
> that experience I know that using this policy leads to issues that are
> very hard to debug. If we make it the default, I expect that it will
> break many existing services that users have built.
I agree with you. Lets keep it as an option to configure since that may
cause
unexpected problems for existing systems.
>
>
> We should really make it configurable, with the parent first policy as
> default. The interesting question is at what level this should be
> configured. I would say that it should be an option in
> service.xml/module.xml, but that makes it probably a bit more
> difficult to implement.
Good suggestion. I'll try to put it at service.xml/module.xml level. If it
really hard
then can only allow at axis2.xml
thanks,
Amila.
>
>
> Andreas
>
> On Fri, May 15, 2009 at 16:14, Amila Suriarachchi
> <am...@gmail.com> wrote:
> > hi all,
> >
> > Currently Axis2 follows the parent first class loading for service and
> > module loading.
> >
> > The reason for this is it uses DeploymentClassLoader loader which is
> > extended from the ClassLoader class.
> >
> > The loadClass method of the ClassLoader class looks like this.
> >
> > protected synchronized Class<?> loadClass(String name, boolean resolve)
> > throws ClassNotFoundException
> > {
> > // First, check if the class has already been loaded
> > Class c = findLoadedClass(name);
> > if (c == null) {
> > try {
> > if (parent != null) {
> > c = parent.loadClass(name, false);
> > } else {
> > c = findBootstrapClass0(name);
> > }
> > } catch (ClassNotFoundException e) {
> > // If still not found, then invoke findClass in order
> > // to find the class.
> > c = findClass(name);
> > }
> > }
> > if (resolve) {
> > resolveClass(c);
> > }
> > return c;
> > }
> >
> > it first check for parent class loader classes and then for its classes.
> So
> > we can add child first class loading simply reversing this order in a
> > override loadClass method as follows.
> >
> > protected synchronized Class<?> loadClass(String name, boolean resolve)
> > throws ClassNotFoundException {
> >
> > Class c = findLoadedClass(name);
> > if (c == null) {
> > try {
> > c = findClass(name);
> > } catch (Exception e) {
> > c = super.loadClass(name, resolve);
> > }
> > }
> > return c;
> > }
> >
> > I have attach the patch here[1].
> >
> > I tested this with a sample service and it worked fine. Will do some
> tests
> > with the modules as well.
> >
> > I think this should be the default behaviour to axis2 since it allows
> people
> > to use their own classes at the service/module level.
> >
> > Any thoughts?
> >
> > thanks,
> > Amila.
> >
> >
> > [1] https://issues.apache.org/jira/browse/AXIS2-4349
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2] Child first class loading
Posted by Andreas Veithen <an...@gmail.com>.
+1 for allowing parent last class loading, but -1 for making it the
default. The reason is that I once worked on a larger project where we
had to use parent last class loading (because we needed a newer
version of some library that was exposed by the app server), and from
that experience I know that using this policy leads to issues that are
very hard to debug. If we make it the default, I expect that it will
break many existing services that users have built.
We should really make it configurable, with the parent first policy as
default. The interesting question is at what level this should be
configured. I would say that it should be an option in
service.xml/module.xml, but that makes it probably a bit more
difficult to implement.
Andreas
On Fri, May 15, 2009 at 16:14, Amila Suriarachchi
<am...@gmail.com> wrote:
> hi all,
>
> Currently Axis2 follows the parent first class loading for service and
> module loading.
>
> The reason for this is it uses DeploymentClassLoader loader which is
> extended from the ClassLoader class.
>
> The loadClass method of the ClassLoader class looks like this.
>
> protected synchronized Class<?> loadClass(String name, boolean resolve)
> throws ClassNotFoundException
> {
> // First, check if the class has already been loaded
> Class c = findLoadedClass(name);
> if (c == null) {
> try {
> if (parent != null) {
> c = parent.loadClass(name, false);
> } else {
> c = findBootstrapClass0(name);
> }
> } catch (ClassNotFoundException e) {
> // If still not found, then invoke findClass in order
> // to find the class.
> c = findClass(name);
> }
> }
> if (resolve) {
> resolveClass(c);
> }
> return c;
> }
>
> it first check for parent class loader classes and then for its classes. So
> we can add child first class loading simply reversing this order in a
> override loadClass method as follows.
>
> protected synchronized Class<?> loadClass(String name, boolean resolve)
> throws ClassNotFoundException {
>
> Class c = findLoadedClass(name);
> if (c == null) {
> try {
> c = findClass(name);
> } catch (Exception e) {
> c = super.loadClass(name, resolve);
> }
> }
> return c;
> }
>
> I have attach the patch here[1].
>
> I tested this with a sample service and it worked fine. Will do some tests
> with the modules as well.
>
> I think this should be the default behaviour to axis2 since it allows people
> to use their own classes at the service/module level.
>
> Any thoughts?
>
> thanks,
> Amila.
>
>
> [1] https://issues.apache.org/jira/browse/AXIS2-4349
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>