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.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
