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
