On Tue, 16 Jul 2002 08:46, [EMAIL PROTECTED] wrote:
> On Mon, 15 Jul 2002, Steve Loughran wrote:
> > > Catalina is as follows:
> > >
> > > Bootstrap
> > >
> > > System
> > >
> > > Common
> > > / \
> > > Catalina Shared
> > > / \
> > > Webapp1 Webapp2 ...
> > > / /
> > > Jasper1 Jasper2
> >
> > And common/lib is marked as endorsed for java1.4, so you have to add new
> > javax. stuff (like jaxrpc.jar) to that lib, rather than in your webapp,
> > just to make installing axis harder. I'd hope we dont replicate that
> > problem, if we can avoid it.
>
> When I mentioned a tomcat-like hierarchy I certainly didn't meant the
> full tree - at least not for 1.6 :-)
>
> There are 2 things in tomcat classloader worth considering for ant:
>
> - the webapp class loader that can use Manifest entries to find
> and resolve dependencies, as well as allow 'webapps' to override some
> classes ( as required by the servlet2.3 spec - but that can be used
> in ant as well).
This is what myrmidon does. It's a quite powerful approach, since you declare
the dependencies in logical rather than physical terms. ie you declare 'I
need junit' or 'I need junit version 3.7', rather than 'I need junit.jar'.
This gives the container heaps of flexibility in how it actually finds the
extensions (ie dependencies) that a jar needs.
In myrmidon, we've made extension resolution pluggable, and you can combine
resolvers at runtime. For example, we have a resolver that looks for
extensions in $ANT_HOME/ext, another that maps the 'com.sun.tools' extension
to the JDK's tools.jar, another that provides a JAXP parser, and one that
makes antlibs available as extensions when they get imported. One that
downloaded jars as needed wouldn't be a big deal to add.
Another good thing that comes from using the extensions mechanism, is that you
can use it in build files as well. For example, in myrmidon, we have a
<path> implementation that returns the path for an extension. You can use
this when compiling, packaging, and running your task/app/tests/whatever, and
your build file does not need to know where the jars actually live. eg:
<path id="myclasspath">
<library-path name="junit" version="3.7+"/>
<library-path name="com.sun.tools"/>
</path>
<javac classpath="${myclasspath}" ... />
(of course, you need poymorhpic types for this to work, but you get the idea.)
> - a hierarchy that is more flexible than 'all jars in CLASSPATH' -
> I think most problems can be solved by just 3 layers ( core,
> optional + global taskdefs, taskdefs with specific loader ). If
> needed we can also use a separate loader for 'server' ( in our
> case ant ). And in time we can enhance it further.
The classloader heirarchy in myrmidon looks something like the tomcat one:
Bootstrap
System
Common
/ \
Myrmidon Shared
/ \
antlib1 antlib2 ...
Each antlib is loaded in its own classloader. We've split Optional.jar and
most of the core tasks, into several antlibs.
--
Adam
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
