On Thu, 1 Nov 2001 16:00, Serge Knystautas wrote:
> Peter,
>
> After trying (and failing) to get mailets loading from anything besides
> james.bar, I read your message from Sept 30. First, let me explain what I
> want to do (in james), what I tried, and what happened:
kool.
> Ideally james.sar could create an app/james/classes directory, that I would
> probably populate with a sample mailet if necessary, and any class in this
> classes directory would get loaded by the
> org.apache.avalon.phoenix.components.classloader.PolicyClassLoader that
> loads the bars in apps/james/blocks and jars in apps/james/lib. Perhaps
> this could get loaded by a classloader that has this PolicyClassLoader as a
> parent so that the apps/james/classes classloader could be recycled so I
> could reload mailet classes without needing to reload all the James
> classes.
In theory all the jars in blocks/ and lib/ directory should be loaded via the
same ClassLoader (However we experimented with a few things re ClassLoader a
bit back so that may have caused issues). So in theory you should be able to
do something like the following.
BlockContext context = ...;
File homeDir = context.getHomeDirectory();
File classesDir = new File( homeDir, "classes" );
URL[] urls = new URL[] { classesDir.toURL() };
ClassLoader parent = James.class.getClassLoader();
URLClassLoader classloader = URLClassLoader.newInstance( urls, parent );
then in theory you should be able to load mailets/matchers out of this
classloader. You should also be able to throw it away later and reload it all
providing that all matchers/mailets are in classes/ directory.
> If that's too ambitious for now, I would like to be able to add a jar to
> the app/james/lib directory and have it load. Unfortunately it seems the
> sar remembers what jars it put in apps/james/lib, and if I put another jar
> in there, avalon ignores it.
As it was then the .sar is only extracted the first time it is spotted. So if
you want ti to be extracted again it is necessary to delete the directory.
Though I have been thinking about a few things related to this of late. Stay
tuned ;)
> My last recourse was to put my jar in the core lib directory, which gets
> loaded by sun.misc.Launcher$ExtClassLoader, because the run scripts now set
> that lib folder as the ext folder. Unfortunately mailets in there can't
> access the mailet.jar, mail.jar, or activation.jar classes, so the server
> just hangs (kind of weird... never throws any exception... I would if this
> is a bug in the ExtClassLoader).
eek - no idea ;)
> Mapping out a series of ClassLoaders might be useful, but as you mentioned,
> I'm not sure how that would look in server.xml. Do you need the extra
> method to BlockContext to get the classloader since on object in that block
> would return the same thing by calling getClass().getClassLoader(), or
> would it return something different?
well it could return something different - depending on which ClassLoader you
asked for. For instance in the other thread where I was discussin similar
things with Paul you may want to
ClassLoader classLoader = getClassLoader( "client-api" );
which would get the class loader that only contained mailet.jar in it.
--
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
