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 <[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]> 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" <[email protected]> Reply to: "Avalon Developers List" <[email protected]> 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:[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]>
