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
>
This archive was generated by hypermail 2.0.0 : Sun Jul 23 2006 - 06:55:59 EDT