axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: [Axis2] Child first class loading
Date Mon, 18 May 2009 19:37:27 GMT
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 <afkham@gmail.com> wrote:
> On Tue, May 19, 2009 at 12:24 AM, Andreas Veithen
> <andreas.veithen@gmail.com> wrote:
>> On Mon, May 18, 2009 at 15:46, Afkham Azeez <afkham@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
>>> <andreas.veithen@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
>>>> <amilasuriarachchi@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
>

Mime
View raw message