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:16:42 GMT
Tomcat is indeed a better analogy and there are actually two other key
points that Tomcat (or the servlet spec) uses to avoid problems
related to parent-last class loading:

1. The parent class loader in Tomcat only exposes the classes that are
strictly necessary. This means that in general you actually don't care
about parent-first or parent-last (except for the notoriously
difficult logging setup).

2. Classes that are referenced in the API exposed by the container are
never loaded from the child class loader. For a servlet container this
is fairly easy because all these classes are either part of the JRE or
the servlet and JSP API. This is why the servlet specs say that
classes from javax.servlet must never be loaded from WEB-INF/classes
or WEB-INF/lib. I don't think it's possible to easily establish a
similar list of "prohibited" packages for Axis2.

Andreas

On Mon, May 18, 2009 at 17:06, Jason Fager <jason.fager@riskmetrics.com> wrote:
> 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