axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Fager <jason.fa...@riskmetrics.com>
Subject Re: [Axis2] Child first class loading
Date Mon, 18 May 2009 15:06:11 GMT
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
> <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


Mime
View raw message