----- 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.
>
> It's slow going, so don't expect it in the next Avalon release....

Berin!  Thanks for responding!

As per your instructions, here's what I've done..
1. Changed
<repository type="MAIL" model="SYNCHRONOUS, ASYNCHRONOUS"
destination="file://" class="org.apache.james.AvalonMailRepository"/>
to...
<repository type="MAIL" model="SYNCHRONOUS, ASYNCHRONOUS"
destination="file://" class="org.apache.james.AvalonMailRepository">
<sampleParam>testing</sampleParam>
</repository>
2. Had AvalonMailRepository implement org.apache.avalon.Configurable.
3. Added the following method:
public void setConfiguration(Configuration conf) {
    System.err.println("This method was called.");
}

Unfortunately when I recompile and restart JAMES, I don't get any message.
Do I need to change the interface (specified in the type attribute) to
implement Configuration?  The way we retrieve repositories is to call
store.getPrivateRepository from the avalon tree
(org.apache.avalon.blocks.Store I believe), so I don't think JAMES would be
calling the setConfiguration parameter, and I'm not sure how we'd even get
ahold of the correct part of the DOM tree.

Any suggestions?

> This is a feature as far as I know.  I also want to upgrade the TimeServer
> to be a Scheduler (a combination of chron and at daemons).  Again don't
> expect this anytime soon.  If you want something to fire in 0
milliseconds,
> what's wrong with using the ThreadManager to fire off a thread
(essentially
> what TimeServer does) and run your event?

No worries here... after a lot of thought, I realized we really didn't want
new threads spawning anyway.  I changed the outgoing messages system into a
spool with a few delivery threads spawn that watch that spool and deliver
when something is available.  With the old approach, JAMES might have
spawned 300 threads to deliver to different mail servers all at once.  Was a
little tricky getting the spool to know when to not return a delayed
message, but after some tweaking, things are working well.

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]

Reply via email to