From: Peter Donald To: Avalon Development Subject: [phoenix] RT: ClassLoader hierarchy Date: Sun, 30 Sep 2001 19:15:58 +1000 Hi, Currently Phoenix has a relatively simple ClassLoader mechanism. It has the following layout System ClassLoader <--- Kernel ClassLoader <--- Application ClassLoader (s) The System ClassLoader includes avalon-framework.jar, phoenix-client.jar and any other jars included in ${phoenix.home}/lib/ (currently xerces and excalibur are required). This works great if you are just writing normal server applications. The problem arises when you try to write applications that will in turn host other components. For instance a servlet container requires a very specific ClassLoader hierarchy for it to work. For instance the base ClassLoader is meant to only contain a handful of files (including servlet.jar and various other "common" jar files). However we can only partially implement that at the moment by placing the library files into ${phoenix.home}/lib however even that case we can not remove avalon-framework.jar, phoenix-client.jar, etc as they are required so that Application and Kernel can talk. So in reality it would be difficult to implement a fully compliant EJB, Servlet etc application without writing another ClassLoader (that didn't delegate to top of ClassLoader hierarchy). A few servlet engines already do this but I would prefer if it was easier in Phoenix. My initial thoughts were to create something like System ClassLoader <--- Common ClassLoader <--- Kernel ClassLoader <--- Application ClassLoader (s) where Common ClassLoader contains avalon-framework.jar, phoenix-client.jar, excalibur etc. That way the Application could create a ClassLoader that delegated to System ClassLoader but wasn't pollutted by Avalon specific jars. However then I thought that this could be bad because some Applications require that extra elements be added to Common ClassLoader that this wouldn't work. ie A servlet container would still require that servlet.jar be loaded by Application ClassLoader (or one of it's parents) and thus you would still have to stuff the servlet.jar into System ClassLoader for this to work. And this is not a good thing IMHO. So then I got to thinking about something Paul said. Maybe we could declare ClassLoader hierarhy in the server.xml. However because a hierarchial ClassLoader still wouldn't work we would have to have an Aggregator ClassLoader that aggregated several ClassLoaders together so we could do something like System ClassLoader <--- Common ClassLoader <--- Kernel ClassLoader <---| | Application ClassLoader (s) Servlet ClassLoader <---| This way we could get access to the unpolluted ClassLoader to work as base ClassLoader for web application. This would be the same ClassLoader that the Application used to load the servlet interfaces and thus it would be easy to provide implementation in Application space. As a matter of fact this could be extended so that an arbitrary number of ClassLoaders could be aggregated for application. However this assumes that each ClassLoader aggregated contains separate namespace. ie The same Class can not be available in multiple ClassLoaders for this to work. To support all this we would need to add an extra method to BlockContext to get named ClassLoader and we would have to enhance server.xml to allow ClassLoader hierarchys to be configured in it (not sure on format). Thoughts? -- Cheers, Pete --------------------------------------------------------- Clarke's Third Law: "Any technology distinguishable from magic is insufficiently advanced". --------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: avalon-dev-help@jakarta.apache.org