donaldp 01/11/30 19:57:31 Added: src/xdocs ClassLoader.txt Log: Add Mail describing possible <classloaders/> section in environment.xml Revision Changes Path 1.1 jakarta-avalon-phoenix/src/xdocs/ClassLoader.txt Index: ClassLoader.txt =================================================================== This is the mail in which the <classloaders/> section in environment.xml was proposed. From: Peter Donald <[EMAIL PROTECTED]> To: Avalon Development <[email protected]> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
