Hi,
(loads of points touched on in this mail, if you want to start a
detailed discussion of any of them can you put them in separate posts
for clarity.)
Yesterday I made some refactorings to the fork in the sandbox to play
with JNDI instead of avalon for service location.
Sadly I had to rush off with my changes uncomitted, but I thought I'd
give you an update anyway.
First of all on a practical level it works a treat (means "very well")
with o.a.naming from the directory sandbox (jars checked in to the
fork).
It works seamlessly with Avalon, because the services and datasources
can be made to bind themselves using a configured name in configure()
or a class constant in initialize() and unbind themselves in dispose().
at the moment I think there should be three or four contexts as follows:
mailet:service/env/datasources
datasources registered by name, requires
a datasource interface for casting the resolved Object.
I think we should probably use javax.sql.DataSource as this will
give us compatibility with driver packages which provide their
own datasource implementations.
mailet:service/env/services
this is for registering and looking up services, it works well with
the dns service. This raises the question of how we manage 3rd party
service lifecycle. We need a MailetService interface and obviously
avalon framework can help us, but is that really the way we want
to go?
mailet:service/env/properties
for global strings which are resolved at runtime like
"helo name" and "confDir"
I'm trying to decide whether we need to mirror the J2EE idea of global and
local contexts, and mappings between global and local bindings. I'm not
convinced, but not 100% sure that it isn't necessary to have local contexts
either.
Eventually I want to focus on the confusion that is the repository management.
Its pretty much a mess at the moment, we have MailRepository, SpoolRepository,
MailStore, and now MailBoxManager.
I think we need to have one interface "MailSource" analogous to datasource,
which permits access to repositories by URL or User, and bind the implementation
of that. This is because the role is not only to provide service location for
repositories but also to manage the creation of repositories.
I tend to think that the same is true for UserRepositories , and that a
User should also be able to satisfy "getInbox()" perhaps with the help of
adding a domain attribute to User, but we're getting into the realm of
virtual hosting again.
Anyway, next I'm probably going to factor out the globals that we
have, user inboxes
for instance, sort out the local delivery mailet and remove "store" from the
MailetContext.
I'll drop another line to this list sometime after I commit this
stuff, so you can
take a look, but in the meantime please discuss!
d.
