----- Original Message -----
From: "Serge Knystautas" <[EMAIL PROTECTED]>
To: "Java Apache Mail Server" <[EMAIL PROTECTED]>
Sent: Tuesday, October 10, 2000 2:10 PM
Subject: Re: Avalon questions
> ----- Original Message -----
> From: "Berin Loritsch" <[EMAIL PROTECTED]>
> > I am currently rewriting the configuration engine; however, this is
> possible.
> > The current configuration engine blindly builds a simpler DOM like
> configuration
> > tree. If you make the <repository> tag so that it is not empty, you will
> have
> > child Configuraiton objects.
> >
> > Your org.apache.james.AvalonMailRepository will have to be Configurable,
> and
> > you simply pass the child Configuration (the whole sub-tree will be
> passed).
> >
> > The new configuration system will have a way to not only type check and
> validate
> > your Configuration objects, but prepopulate things like the class
> attribute
> > so that the administrator doesn't have to see that--it's the developer's
> job.
>
> I did a little more investigating, and it doesn't seem that what you suggest
> is possible. The Store component JAMES receives is the class
> org.apache.avalon.blocks.masterstore.MasterStore. In that class,
> getPrivateRepository calls instantiateRepository(), which does not support
> checking for children configurations... just creates the object, calls
> setAttributes() and setComponentManager() and that's it.
Is that what the MasterStore does? That needs to be changed.
> I'm guessing it's because we're working on an older version of avalon... the
> branch we use is avalon-james-1-1b1 (branched last June/early July). It's
> hard to completely understand the CVS logs of a project you've never worked
> on, but it seems donaldp patched this class mid August to support
> Configurable repositories.
We'll have to check, but if he did that it would be great. He's done alot
adding SecurityManager hooks and a default logging implementation.
> Which I guess brings me to my next question... how close or how recent is a
> release of Avalon? I would hope much of what has changed isn't too
> significant and if anything we could have more features like the ones
> convered here. Charles and I are creating some workarounds at this point,
> and I think we're just about at that point where it'd be better to move to
> the next Avalon than write more code that need to get overhauled.
I wish I could say with any authority. I can say is we are closer now than
we have ever been. It depends on a couple of things that we are cleaning up.
Every time I say, "Real soon now," it never happens. This time I will keep
my mouth shut, and see how long....
> Anyway, I still want to write a bit more documentation on how to write more
> mailets and matchers, but I think we're just about ready for 1.2 to go out.
> I made some copious commits last night that hopefully anyone who's
> interested can have a chance to review. These aren't complete notes, but
> this is some of what I changed:
>
> (in the mailet API)
> - added new MailAddress(InternetAddress) constructor to ease integration
> with JavaMail
> - proper parsing in the MailAddress(String) constructor
> - changed MailetContext.bounce methods to throw MessagingException (since
> they basically just wrap sendMail which throws this, it makes sense)
> - added "sendMail(MimeMessage msg) throws MessagingException", to
> MailetContext to simplify how messages can be sent.
>
> (in JAMES itself)
> - Reworked remote delivery. All messages immediately get put in the
> outgoing spool repository. Delivery threads watch this pool for new mail
> and grab them for delivery. Messages that have failed are delayed before
> attempting again.
> - Abstracted GenericListserv and made AvalonListserv and TownListserv
> - Wrote TownListserv
> - Wrote TownAlias
> - Wrote Error message bouncer mailet for error processor
> - build.xml generates the mailet.jar as a separate jar
>
> (to do still)
> - Finish up listservs
> - Write mailet and matcher document (list of the ones that are supported,
> and what they do)
> - Update todo.xml, changes.xml
> - Update documentation for 1.2 release
> - Write changelog since version 1.1
Sounds good. Avalon is coming along as well. In the next version expect
the following:
- Logger and ThreadManager are system level now (with Block level managers)
- A new complement to ComponentManager: ComponentSelector. ComponentSelector
is to choose among several Components that fulfill the same Role.
ComponentManager is to choose Components among different Roles.
- A security managed kernel
- Command line tool
- Object pooling
- The beginnings of XML based internationalization.
- Much improved documentation! It is split into administration, developer,
and block implementor docs.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
