1 2 Previous Next 15 Replies Latest reply on Aug 16, 2003 11:40 AM by timfox Go to original post
      • 15. Re: why does AOP use its own class loader?
        timfox

        Sorry I've been away for a while...
        The subject of AOP use in Tomcat/Jetty or any other 3rd party application is an interesting one.
        The problem is that you have to somehow change the application's ClassLoaders to add the code that does the advising.
        In a 3rd party application there may be a very complex ClassLoader structure that you either don't want to break, or can't since you don't have access to the source it (ie not OSS).
        So what can you do?
        One solution I have come up with is the concept of a "ViralClassLoader" as I call it.
        When you start the application you supply a parameter that causes the ViralClassLoader to be used as the system classloader instead of the default one (-Djava.system.class.loader).
        This classloader has the ability to advise the code of any classes it loads.
        But what happens if the 3rd party application goes on to use other classloaders internally for other purposes? These classloaders will also need to be changed so that they can advise the classes they load.
        This is where the ViralLoader steps in. When it loads a class it checks if the class is itself another ClassLoader, and if it is, it then instruments that class with the code that checks whether any classes loaded by that class are ClassLoaders themselves.
        If you're still with me, you'll realise that this allows any classloaders (apart from the internal classloader that loads system classes) used by the application to be changed such that they can advise the classes they load, without any changes to the application code.
        The advising code is passed "virally" into any ClassLoader when it is loaded.
        As long as you have the ability to do -Djava.system.class.loader=blah.ViralLoader then you can effectively add AOP to any application without access to the source code, and without changing the application's ClassLoader hierarchy.
        I've currently got this working with Resin, allowing me to instrument classes retrieved from calls to JBoss EJBs. I haven't tried it with Tomcat or Jetty but I don't see why it shouldn't work with them, or with weblogic for that matter, or anything else.
        If anyone's interested I can supply some code.

        1 2 Previous Next