james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MantissaHotmail" <freddd...@hotmail.com>
Subject James does not send mails
Date Sun, 19 Sep 2004 12:18:23 GMT
Hi,
    Since last wednesday (9/15), james stop sending mails, the smtp is
alive, you can use it, but james does not send the mails in the outgoing
folder (my outgoing folder in the moment has more than 4000 mails..). I
restarted james several times but nothing happened, and I can find no error
messages.
    Can someone help me?
[]s
Freddy
----------------------------------------------------------------
Frederico Silva GuimarĂ£es
Tel: (21) 9952-1717
ICQ: 127277403
Email: kid@teccomm.les.inf.puc-rio.br
----------------------------------------------------------------

----- Original Message ----- 
From: "Steve Brewin" <sbrewin@synsys.com>
To: "'James Developers List'" <server-dev@james.apache.org>
Sent: Friday, September 17, 2004 5:39 PM
Subject: RE: Indestructible repositories


> Hi Jason,
>
> Jason Webb wrote:
>> I'm posting this here rather than the Avalon list because I
>> can't work out
>> if my problem is a James issue due to usage or an Avalon issue due to
>> implementation...
>>
>> It seems that it is not possible to delete or rename
>> repositories. These two
>> features are critical for the IMAP work as both are required
>> features of any
>> IMAP host.
>
> What are the IMAP use case scenarios which require a repository to be
> deleted or renamed? Knowing what needs to be achieved at a higher level
> might help us to identify the best solution. Besides, I'm curious.
>>
>> Therefore who should be responsible for deleting/renaming
>> repositories?
>> My current opinion is that this should be done at the Mail Repository
>> interface level and thus the repository implementers issue.
>
> My take is that it should be the responsibility of the same object that
> creates the repository, rather than the repository object itself.
> Typically
> this should be a singleton manager object.
>
> In a hierarchy of objects, helper methods are often added to the
> hierarchical elements so that parent objects are responsible for managing
> their children. This is analogous to a file system where we send messages
> to
> a parent directory to create/delete/rename a file within it. Under the
> covers, these methods delegate to the manager. It implies that a root node
> is preconfigured, such as '/' in *nix file systems.
>
> We should not ask objects "at the MailRepository interface level" to
> destroy
> or rename themselves. This leads to 'ghost' objects in memory which no
> longer represent real objects in the underlying repository. From an OO
> sense
> its wrong as the connected entity should have no knowledge of how it is
> connected and hence should not assume to know how to disconnect itself.
>
> Unfortunately, I don't have the code in front of me right now to check if
> we
> are using the manager approach or have any of the elements in place to
> support such an approach.
>
> One implementation of this approach would be an AbstractFactory,
> "RepositoryManager", which delegates to concrete Factories, one for each
> kind of repository. The operations would include create, copy, move (aka
> rename) and delete. For James cooked repository implementations we would
> have to do all of the work. For other repositories, such as Avalon, the
> concrete "AvalonRepositoryManager" may be able to leverage existing Avalon
> functionality if it exists - it might, I'm no expert. I would ask the
> Avalon
> group.
>
> Not sure if this really helps, and as I've already said, I'm not sure what
> is in the code base. Finally, just to be really helpful, I'm off sailing
> for
> a week from Sunday, so will not be responding immediately to any
> discussion
> this may provoke.
>
> Cheers,
>
> -- Steve
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message