Sorry for the cross post, but this idea involves both groups.
(a bit of a background first...)
Right now JAMES is based on a branch in avalon's CVS tree named
avalon-james-1-1b1. (This branch was made in late June 2000 and we see
Avalon 2.2-dev on startup). The JAMES group is planning to make a new
(version 1.2) release based on this branch, and as the next release will
include migrating to the latest avalon release.
One feature of avalon we've attempted to leverage is the idea of pluggable
repositories. We use MailRepositories, SpoolRepositories (an extension of
MailRepositories), and UserRepositories. With this, we've added some new
database driven mail/spool repositories and an ldap user repository. The
problem I'm struggling with right now is that with the branch we're using,
repositories are not configurable. This makes repositories somewhat
difficult as we end up putting lots of conf settings into a URL, or do some
other workaround that's even less elegant.
I propose as to make the 1.2 version cleaner (and simpler to administer), I
apply a patch to org.apache.avalon.blocks.masterstore.MasterStore to see if
the repository it is instantiating is configurable, and if it is, pass a
Configuration object. I'm pretty confident this is the object that's
instantiating these repository objects, and this would be a rather small
change. Once this patch was made, I could generate new avalon jars and put
these new jars into the JAMES cvs tree and distribution for 1.2.
>From looking over the latest Avalon release, repositories are configurable,
so it seems this will only help us later transition to Avalon, and in the
meantime, it lets me clean up some code and make the configuration more
flexible and more readable. (avalon developers will hopefully point out if
this is a pointless change as these concepts will get significantly changed
in the new avalon release).
Any comments? I'm planning to do whatever it takes on JAMES this weekend to
make it ready for 1.2 and would like to do this as part of that. Sorry for
giving so little time to think about this, but I just really thought of it a
day or two ago and had the chance to look over the code tonight.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
