avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dona...@apache.org
Subject cvs commit: jakarta-avalon-excalibur/info/src/xdocs ClassLoader.txt
Date Sat, 14 Sep 2002 07:10:53 GMT
donaldp     2002/09/14 00:10:53

  Added:       info/src/xdocs ClassLoader.txt
  Log:
  Copy across ClassLoader hoo-haa from Phoenix.
  
  Revision  Changes    Path
  1.1                  jakarta-avalon-excalibur/info/src/xdocs/ClassLoader.txt
  
  Index: ClassLoader.txt
  ===================================================================
  This is the mail in which the <classloaders/> section in 
  environment.xml was proposed.
  
  From: Peter Donald <peter at apache.org>
  To: Avalon Development <avalon-dev@jakarta.apache.org>
  Subject: [phoenix] ClassLoader section in environment.xml
  Date: Sat, 1 Dec 2001 15:07:28 +1100
  
  Hi,
  
  Heres some thoughts about a possible way to define ClassLoader structure in 
  the environment.xml file. Tell us what you think
  
  <classloaders default="*application*">
    <classloader name="foo" parent="*api*">
      <entry location="sar:/some/dir/classes"/>
      <entry location="sar:/some/dir/mypackage.jar"/>
      <entry url="http://www.realityforge.org/some.jar"/>
    </classloader>
  
    <classloader name="bar" parent="*system*">
      <extension>
        <name>javax.servlet</name>
        <specification-version>2.3</specification-version>
        <vendor-id>org.apache.jakarta</vendor-id>
        <vendor-version>1.2.3.4</vendor-version>
      </extension>
    </classloader>
  
    <join name="baz">
       <classloader name="foo">
       <classloader name="bar">
    </join>
  
    <classloader name="common" parent="bar">
      <entry location="sar:/some/more/classes"/>
    </classloader>
  
  </classloaders>
  
  So in this case we have explicitly defined 4 classloaders; foo, bar, baz and 
  common. The names of these classloaders are completely arbitrary. You will 
  notice that I also refer to other predefined classloaders. These special 
  classloaders can not be overiden and are defined by system. They are
  
  o *system* (The System classloader)
  
  o *api* (The classloader for phoenix API - will just contain framework.jar 
  and phoenix-client.jar in future but now contains a wealth of other jars)
  
  o *common* (The classloader that is shared between apps and container - empty 
  now but will contain things like excalibur classes)
  
  o *application* (Contains contents of SAR-INF/lib/*.jar + SAR-INF/classes. I 
  am not sure if this is strictly needed though ...)
  
  The <join/> classloader assumes that each classloader that it is made up of 
  has a disjoint set of classes/resources contained in it. So it was the 
  "aggregator" ClassLoader I was talking about.	
  
  You will also notice the "default" attribute of <classloaders/> section. This 
  specifies the ClassLoader via which the blocks are loaded. The only 
  requirement being that one of it's parent classloaders must be "*api*".
  
  So if/when this is implemented what does it mean ? Well we could finally 
  implement a spec complaint servlet engine without jumping through loops. See 
  below for a sample of how I would do it. We could also support nested 
  "applications" like Stephen wanted. Woohoo!
  
  <classloaders default="servlet-container">
  
    <classloader name="jndi-api" parent="*system*">
      <entry location="sar:SAR-INF/ext/jndi.jar"/>
    </classloader>
  
    <classloader name="servlet-api" parent="*system*">
      <extension>
        <name>javax.servlet</name>
        <specification-version>2.3</specification-version>
        <vendor-id>org.apache.jakarta</vendor-id>
        <vendor-version>1.2.3.4</vendor-version>
      </extension>
    </classloader>
  
    <join name="common">
       <classloader name="servlet-api"/>
       <classloader name="jndi-api"/>
    </join>
  
    <classloader name="servlet-container" parent="common">
      <entry location="sar:SAR-INF/lib/*.jar"/>
      <entry location="sar:SAR-INF/classes/"/>
    </classloader>
  
  </classloaders>
  
  Anyways - thoughts?
   
  -- 
  Cheers,
  
  Pete
  
  *----------------------------------------------*
  | The best defense against logic is ignorance. |
  *----------------------------------------------*
  
  --
  To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
  For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
  
  
  Re: [phoenix] ClassLoader section in environment.xml
  Date: Sat, 1 Dec 2001 15:36:21 +1100
  From: Peter Donald <peter at apache.org>
   To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
  Reply to: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
  
   Hi,
  
  One thing I forgot to mention was how Blocks aquire the ClassLoaders. I 
  propose that we add another method to BlockContext interface, namely
  
  ClassLoader getClassLoader(String name)
  
  This raises an interesting question though. How should a Block declare that 
  it needs a ClassLoader named "foo" and "foo" must contain classes X, Y and Z? 
  Should it declare that?
  
  My initial though was that you could add another section to the BlockInfo 
  file like
  
  <classloaders>
    <classloader name="foo">
       <description>
          This ClassLoader must contain classes X, Y and Z. It is 
          part of the foo API and we use it to do "Something".
       </description>
        <required classname="com.biz.ClassToCheckFor"/>
    </classloader>
  </classloaders>
  
  Then I realized - what would happen if 2 Blocks declared that they depended 
  on ClassLoaders named "foo" but which had different contents. So in this case 
  it would be required that you map the application-wide name into a 
  block-local name ... which seems like overkill/flexability syndrome. 
  
  So options that I could think of are;
  1. ignore the issue and make it a requirement that Block writers document it 
  so that assemblers can build it
  2. have basic structures in blockinfo but keep names global
  3. Same as 3 but we map classloader names from global namespace to 
  application local namespace.
  
  Thoughts?
  
  -- 
  Cheers,
  
  Pete
  
  ---------------------------------------------
   We shall not cease from exploration, and the 
    end of all our exploring will be to arrive 
   where we started and know the place for the 
          first time -- T.S. Eliot
  ---------------------------------------------
  
  --
  To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
  For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
  
  

--
To unsubscribe, e-mail:   <mailto:avalon-cvs-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-cvs-help@jakarta.apache.org>


Mime
View raw message