Hi,
Currently Phoenix has a relatively simple ClassLoader mechanism. It has the
following layout
System ClassLoader <--- Kernel ClassLoader
<--- Application ClassLoader (s)
The System ClassLoader includes avalon-framework.jar, phoenix-client.jar and
any other jars included in ${phoenix.home}/lib/ (currently xerces and
excalibur are required).
This works great if you are just writing normal server applications. The
problem arises when you try to write applications that will in turn host
other components. For instance a servlet container requires a very specific
ClassLoader hierarchy for it to work. For instance the base ClassLoader is
meant to only contain a handful of files (including servlet.jar and various
other "common" jar files).
However we can only partially implement that at the moment by placing the
library files into ${phoenix.home}/lib however even that case we can not
remove avalon-framework.jar, phoenix-client.jar, etc as they are required so
that Application and Kernel can talk. So in reality it would be difficult to
implement a fully compliant EJB, Servlet etc application without writing
another ClassLoader (that didn't delegate to top of ClassLoader hierarchy). A
few servlet engines already do this but I would prefer if it was easier in
Phoenix.
My initial thoughts were to create something like
System ClassLoader <--- Common ClassLoader <--- Kernel ClassLoader
<--- Application ClassLoader (s)
where Common ClassLoader contains avalon-framework.jar, phoenix-client.jar,
excalibur etc.
That way the Application could create a ClassLoader that delegated to System
ClassLoader but wasn't pollutted by Avalon specific jars.
However then I thought that this could be bad because some Applications
require that extra elements be added to Common ClassLoader that this wouldn't
work. ie A servlet container would still require that servlet.jar be loaded
by Application ClassLoader (or one of it's parents) and thus you would still
have to stuff the servlet.jar into System ClassLoader for this to work. And
this is not a good thing IMHO.
So then I got to thinking about something Paul said. Maybe we could declare
ClassLoader hierarhy in the server.xml. However because a hierarchial
ClassLoader still wouldn't work we would have to have an Aggregator
ClassLoader that aggregated several ClassLoaders together so we could do
something like
System ClassLoader <--- Common ClassLoader <--- Kernel ClassLoader
<---|
| Application ClassLoader (s)
Servlet ClassLoader <---|
This way we could get access to the unpolluted ClassLoader to work as base
ClassLoader for web application. This would be the same ClassLoader that the
Application used to load the servlet interfaces and thus it would be easy to
provide implementation in Application space.
As a matter of fact this could be extended so that an arbitrary number of
ClassLoaders could be aggregated for application. However this assumes that
each ClassLoader aggregated contains separate namespace. ie The same Class
can not be available in multiple ClassLoaders for this to work.
To support all this we would need to add an extra method to BlockContext to
get named ClassLoader and we would have to enhance server.xml to allow
ClassLoader hierarchys to be configured in it (not sure on format).
Thoughts?
--
Cheers,
Pete
---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from
magic is insufficiently advanced".
---------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
