Andrus Adamchik wrote:
On Jul 22, 2006, at 11:52 PM, Kevin Duffey wrote:
I have not joined the cayenne-dev list, so I may not see some replies.
I am on about 17 mailing lists right now and while I do not mean any
offense, I don't have the time to start developing on a new project.
Certainly no offense, but see related comments below.
A few thoughts since Andrus has emailed Evert and I. First, I would
like to explore Evert's "2.0" codebase a bit, possibly with Evert and
Andrus on IM if there is any possibility we can all three meet. I know
I am in California, PST and Evert is Netherlands. I am on Yahoo IM as
is Evert if Andrus, you could maybe join up (if you dont have Yahoo
account) and meet with us, or we can log in to any IRC server (usually
EFNET works well) and chat in a private channel. Does this work for
you Andrus... if so, yahoo/irc? Anyone else on the cayenne project is
welcome to join as well.
We are (almost) an Apache project, so we do things via mailing lists. I
would suggest to do the same here, and avoid the timezone mismatch
problems at the same time :-) To save you from the flood of unrelated
traffic on cayenne-dev, I just subscribed to platonos-plugeng-dev. Let's
communicate via that list, so there will be a track record for anybody
who would want to jump on it later. This is important.
The 2.0 codebase is a rewrite of the engine from scratch. It shares
many of the same ideas, especially at the classloader level, but we
ran into some snags with plugin dependencies (primarily circular
references where plugin A depends on B, B on C and C on A.. not a good
thing to do).
I still need to check out 2.0. Hopefully I'll have time tomorrow.
As well, Evert, who did most of the unload coding of plugins, learned
that there is quite a problem in trying to unload plugins once one
plugin grabs a ref to any class in another plugin. I used to
contribute to the Eclipse Equniox project, and learned from them that
they basically unload the entire plugin stack to do a runtime reload
of just a single plugin, depending on the dependency complexities.
Anyway, don't want to delve into that now, just a heads up of why the
2.0 codebase may be the way to go, especially if a few of you on the
cayenne project will help contributes to it (both code and ideas).
Yes, the unloading of plugins can be difficult. A classLoader loads
classes and while there are still references to one or more of the
classes that were loaded by a classloader they will not be garbage
collected. So for example, if plugin B implements an interface from
plugin A, then plugin A can not be unloaded until plugin B has been
unloaded.
Btw, we have two kinds of plugins, directory plugins and plugin archive
plugins.
Directory plugins are plugins that have the classes and other resources
in a directory.
Archive plugins are plugins that are stored in an zip based archive,
default file extensions are .par and .jar but other file extensions
could be configured (by code) to if desired. The only extra feature a
plugin archive has is that it can also contain embeded zip basesd
archives, so you can bundle your class libraries in the plugin archive.
No code changes are needed in plugins to be used as archive plugins,
this is handles by our classloader. Archive plugins may be a bit slower
than directory plugins but I try to improve that where I can.
Just like you don't want to delve into Cayenne, we'll probably just be
the "active observers" :-)
Andrus
