On Mon, May 18, 2009 at 8:36 PM, Jason Fager <jason.fa...@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. the child first class loading only effect at the service or module level. Although it is a possibility I think it is a rear case some one need to change the axis2-kernal class in his service or module. On the other hand if some one really needs it, why we need to stop it. I agree with you that Tomcat has a much better class loading hierarchy. But IMHO in this stage we should not try to make it complicated specially with class loading. thanks, Amila. > > > - 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 > > -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
