This is the mail in which the section in
environment.xml was proposed.
From: Peter Donald
To: Avalon Development
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
javax.servlet
2.3
org.apache.jakarta
1.2.3.4
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 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 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!
javax.servlet
2.3
org.apache.jakarta
1.2.3.4
Anyways - thoughts?
--
Cheers,
Pete
*----------------------------------------------*
| The best defense against logic is ignorance. |
*----------------------------------------------*
--
To unsubscribe, e-mail:
For additional commands, e-mail:
Re: [phoenix] ClassLoader section in environment.xml
Date: Sat, 1 Dec 2001 15:36:21 +1100
From: Peter Donald
To: "Avalon Developers List"
Reply to: "Avalon Developers List"
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
This ClassLoader must contain classes X, Y and Z. It is
part of the foo API and we use it to do "Something".
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:
For additional commands, e-mail: