Serge Knystautas wrote:
>
> I was trying to determine the best place to put the MX record lookup
> code, trying not to tie the RemoteDelivery mailet implementation to
> anything in Avalon, when suddenly I realize a very core part of the
> Mailet API is defined by Avalon classes. MailetContext explicitly is an
> Avalon component... what happened? I can't believe I didn't catch this
> sooner... this is pretty important as tying the mailet and matcher
> parameter passing is required to be implemented by Avalon.
>
> So what do we do at this point? We can (and I'm quite happy to) say
> that the Mailet API is only allowed to be implemented in the
> Avalon/Apache framework... I think the API is very powerful, but we have
> to accept that we can't get anyone else to support or implement the API
> the way it is currently defined. (on the other hand, who do we think
> would ever work to support the mailet framework... I don't know.)
>
> Any way, this is a big red flag we should probably address before
> release. Of course I notice this the day Federico is leaving for
> weeks. Oh well... I'm going to probably deploy JAMES as is pretty soon
> for some projects I'm working on. Will send all my patches in this
> weekend.
>
Agree... I tryied to hide that huge hole as long as possible but you're
too smart! :-)
So the goal is: James is avalon aware and can be tied to avalon patterns
and interface ans much as needed.
Mailet should not so we must provide a decoupling layer to make them
really implamantation independent.
What about the next release? :-)
Federico
[EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
