cvs commit: jakarta-avalon-phoenix/src/xdocs ClassLoader2.txt

[do...@apache.org]

donaldp     02/02/11 03:58:38

  Added:       src/xdocs ClassLoader2.txt
  Log:
  Old email blurb about classloaders to remind me to actually implement this!
  
  Revision  Changes    Path
  1.1                  jakarta-avalon-phoenix/src/xdocs/ClassLoader2.txt
  
  Index: ClassLoader2.txt
  ===================================================================
  From: Peter Donald <do...@apache.org>
  To: Avalon Development <av...@jakarta.apache.org>
  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
  
  
  
  
  

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>