Serge Knystautas wrote:
> First of all, thanks! All support is greatly appreciated.
No problem! This project has a lot of potential and a great foundation
of code. Throughout my progress i might have some questions (namely
with stuff that is more Avalon related) I don't have a solid handle on
that yet, but will begin looking into it more.
> If you can, I
> think the UML you've drawn up could help other developers trying to get a
> handle on the code.
Its still alot of work in progress, but when I finish everything I'll be
more than happy to send it in. Currently I have UML for several Mailets
(namely listserv stuff and toRepository) and am currenlty working on the
org.apache.mailet package. I then plan on doing a simple overview of
James with core, services and transport. This I think should clear up a
lot.
> As for the external configuration, I agree the flexibility would be nice.
> I'm not sure on the syntax though. I would prefer to have an attribute on
> the mailet element indicate where the alternate configuration comes from,
> i.e., I think it is confusing to have a nested element dictating
> configuration information in the same place you would otherwise specify
> inline parameters.
I see, and I agree. I'm a little confused on how James handles the
protocols i.e. file:// jdbc:// town://
any suggestions on where I should look that will clear this up for me.
It appears that repositories are choosen out of protocol, type, and
model. Is this accurate?
>
> <mailet config="file:[EMAIL PROTECTED]">
> </mailet>
I like this approach.
question:
file:///listserves is in respect to what directory. I notice
file://var/mail is in respect to <james root>/apps/james ? This is
because of Phoenix, correct? Now should I follow the same approch or
should config files be all rooted to <james root>/apps/james/conf ?
>
> If we could accomplish both these wishes in one approach, I'd prefer that.
Cool.
>
> All of this also gets slightly more complicated because James doesn't know
> how to reload the configuration without a restart. Right now, the external
> source could change, and James wouldn't know to take effect. This may or
> may not be desirable.
I saw this problem and I even posted something a few days ago addressing
it. what I see James missing is the ability to shutdown and restart
from a command line or something? My question now is because James is
built on Avalon Phoenix now is this something that Phoenix should
provide for blocks deployed on it. In otherwords, should Phoenix itself
be shutdown and restarted (not desireable because say you have unrelated
servers running on the same phoenix foundation and you just want to
restart one). I think Phoenix should offer a way to shutdown
(disassemble) specific blocks, and restart them dynamically. Any
thoughts here? Should I address this to the Avalon mailing list (I
should probably join that huh)?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
