You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by do...@apache.org on 2002/09/14 09:10:53 UTC
cvs commit: jakarta-avalon-excalibur/info/src/xdocs ClassLoader.txt
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 <av...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@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" <av...@jakarta.apache.org>
Reply to: "Avalon Developers List" <av...@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: � <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>