On Mon, May 18, 2009 at 15:46, Afkham Azeez <afk...@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
> <andreas.veit...@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
>> <amilasuriarach...@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
>
