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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to