You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Iwasa Kazmi <kz...@ca2.so-net.ne.jp> on 2002/12/10 12:53:29 UTC
About fix of cornerstone, FileRepository
Hello,
I cannot use the latest James because of Bug#8839. My PC have
less resources to run the database software, and it is shutdown
at every night.
I have tried two methods to solve Bug#8839.
(a) add wrapper classes of File_Persistent_Object_Repository
and File_Persistent_Stream_Repository. (These classes are
part of cornerstone) See my sample.
These classes replace AbstractFileRepository#initialize().
(b) replace cornerstone.jar with modified version.
I downloaded a snapshot of 2002-06-04 with cvs, changed
AbstractFileRepository#initialize(), and built all.
The patch is cornerstone-kzmi.diff.
(a) seems to work about mail repository with editing config.xml,
but I couldn't find how to replace class for users repository.
(After restarting of James, user listing/counting failed because of
file-repository bug)
Also, these classes depend on the implementations of cornerstone
which is referred.
(b) seems to work well in any repository. Now I'm using James-cvs
with modified cornerstone.jar.
In my changes, repository-id part is removed from filename and search-pattern. It violates the compatibility of the filename.
But I think such replacement of the cornerstone would be better
for the quality of James, and I would propose to include such improvement in the next measure release.
Regards,
---
Iwasa Kazmi
RE: Mail Repositories
Posted by "Noel J. Bergman" <no...@devtech.com>.
Aaron,
The nature of what should the spooler be has been made before, as I think
you may recall. There are already some notes about how to change it, and
I've bookmarked your message to address when we start work on v3.
In the meantime, would you care to review the documentation, which Peter is
keeping at http://jakarta.apache.org/~pgoldstein? Sooner we finish the
docs, the sooner we start work on v3.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Mail Repositories
Posted by Aaron Knauf <ak...@xtra.co.nz>.
I may be off base here, but it seems to me that the message spooling
mechanism used by the mailet processor is unnecessarily coupled to the
mail repository.
It seems to me that a mail spooler need not be a repository. It does
not necessarily even need to use a repository. It just needs to pull
messages from a message source and submit them to a processor for
processing.
In code, a SpoolRepository /is a/ MailRepository. I cannot see why this
should be the case. If the source of messages used by a message spooler
happens to be a mail repository, the spooler should /compose/ the mail
repository.
I have attached a couple of UML diagrams that outline (at a conceptual
level) how I think it could work. Before you all rush for your
flamethrowers, note the word /conceptual/. Note also that this is very
rough example, intended to demonstrate a decoupling of the repository
from the spool. It is for discussion only and should not not be
construed as a recommendation.
One immediate advantage of this approach is to do away with the need for
AvalonSpoolRepository /and/ JDBCSpoolRepository. One
RepositoryMessageQueue class can use *any* repository for message
persistence.
Note that I suspect that a spool and a repository are not the same
thing, because their purposes are quite different. I have renamed spool
to queue in my model because I think that makes the difference clearer.
A repository is a thing that stores messages for later retrieval. A
queue is a thing that lines messages up for processing. You add a
message to a queue when you want it processed. You save a message to a
repository when you want to keep it for later. Two very different
focuses, despite superficial similarities. IMHO, this means they are
not substitutable and therefore cannot be the same class.
The re-use of MessageReceiver, MessageProcessor and MessageSource to
both receive SMTP messages from the dialog handler and also receive
messages from the queue/spool is just something that I thought might be
interesting. I haven't thought about it too hard, so be gentle with
your flames! ;-)
Cheers
ADK
Noel J. Bergman wrote:
> Charles Benett wrote:
>
>>With regard to the future, providing a maildir implementation is fine
>>but I'd recommend keeping the interface general enough to support other
>>implementations.
>>There were questions about the operation of IMAP versus POP3 which
>>suggested they need different mailbox functionality. When we get to
>>that stage, I guess we need to think about the design requirements
>>for the 4 different mail repositories: SMTP spool, POP3, IMAP and NNTP.
>
>
> Absolutely. My take on repositories is:
>
> We want a single repository interface that is suitable for all message
> stores, including POP, IMAP and NNTP. We need an abstract interface capable
> of supporting search and multiple providers. Personally, I want an
> interface that can be optimized by providers, e.g., if we are using a JDBC
> provider, I want to be able to leverage SQL queries as much as possible.
>
> I have some ideas regarding this, but am postponing them until the v3
> moratorium is lifted.
>
> We have this far found it convenient to use a subclass of our mail
> repository for spooling, but I am not sure if is the best way moving
> forward.
>
> FWIW, I had just written that this morning to the author of a Java maildir
> implementation. He may be interested in contributing to James, and
> mentioned some discussions he had with the JavaMail folks. Apparently there
> may be some willingness to make changes to JavaMail to better fit server
> needs, too.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
Mail Repositories
Posted by "Noel J. Bergman" <no...@devtech.com>.
Charles Benett wrote:
> With regard to the future, providing a maildir implementation is fine
> but I'd recommend keeping the interface general enough to support other
> implementations.
> There were questions about the operation of IMAP versus POP3 which
> suggested they need different mailbox functionality. When we get to
> that stage, I guess we need to think about the design requirements
> for the 4 different mail repositories: SMTP spool, POP3, IMAP and NNTP.
Absolutely. My take on repositories is:
We want a single repository interface that is suitable for all message
stores, including POP, IMAP and NNTP. We need an abstract interface capable
of supporting search and multiple providers. Personally, I want an
interface that can be optimized by providers, e.g., if we are using a JDBC
provider, I want to be able to leverage SQL queries as much as possible.
I have some ideas regarding this, but am postponing them until the v3
moratorium is lifted.
We have this far found it convenient to use a subclass of our mail
repository for spooling, but I am not sure if is the best way moving
forward.
FWIW, I had just written that this morning to the author of a Java maildir
implementation. He may be interested in contributing to James, and
mentioned some discussions he had with the JavaMail folks. Apparently there
may be some willingness to make changes to JavaMail to better fit server
needs, too.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: About fix of cornerstone, FileRepository
Posted by Charles Benett <ch...@apache.org>.
Yes, I saw Peter's email on avalon-dev.
Moving the existing filerepository code to James and fixing it seems
fine to me.
With regard to the future, providing a maildir implementation is fine
but I'd recommend keeping the interface general enough to support other
implementations.
There were questions about the operation of IMAP versus POP3 which
suggested they need different mailbox functionality. When we get to that
stage, I guess we need to think about the design requirements for the 4
different mail repositories: SMTP spool, POP3, IMAP and NNTP.
Cheers,
Charles
Noel J. Bergman wrote:
>I will forward a message from Peter Donald on avalon-dev@, but basically, he
>seems to be saying that the store code within Cornerstone:
>
> a) is badly broken
> b) exists only for James
> c) should be removed from Cornerstone and
> put into our source base
>
>Removing our dependency upon that code, one way or the other, seems like it
>will be a good idea. For the short term, I guess that we should probably
>take the code from Cornerstone, merge it into our CVS, and apply your
>changes. For the longer term (v3), we should replace it entirely. Peter
>(Goldstein) has suggested a maildir solution.
>
> --- Noel
>
>-----Original Message-----
>From: Iwasa Kazmi [mailto:kzmi@ca2.so-net.ne.jp]
>Sent: Wednesday, December 11, 2002 6:08
>To: James Developers List
>Subject: Re: About fix of cornerstone, FileRepository
>
>On Tue, 10 Dec 2002 14:05:33 -0500
>"Noel J. Bergman" <no...@devtech.com> wrote:
>
>
>
>>Your contribution is appreciated, but it might be best if you raised this
>>issue (and your proposed patch) directly to the Avalon developers on
>>avalon-dev@ mailing list. We get the code from that project.
>>
>>
>
> Discussion in Avalon-dev would be good. I think also it would be better
>to do refactoring cornerstone's file repository.
> But the latest James uses old cornerstone which is not replacable
>with the latest one. It means that the repository-bug doesn't
>be fixed until we choose the latest cornerstone after heavy work on
>James.
> You have already wasted over half year from the time Bug#8839 was
>reported. It would be better to provide the solution about it.
>I think wrapping or modifying old cornerstone.jar is one of the quick
>solution.
>
> Regards,
>
>Iwasa Kazmi
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: About fix of cornerstone, FileRepository
Posted by "Noel J. Bergman" <no...@devtech.com>.
I will forward a message from Peter Donald on avalon-dev@, but basically, he
seems to be saying that the store code within Cornerstone:
a) is badly broken
b) exists only for James
c) should be removed from Cornerstone and
put into our source base
Removing our dependency upon that code, one way or the other, seems like it
will be a good idea. For the short term, I guess that we should probably
take the code from Cornerstone, merge it into our CVS, and apply your
changes. For the longer term (v3), we should replace it entirely. Peter
(Goldstein) has suggested a maildir solution.
--- Noel
-----Original Message-----
From: Iwasa Kazmi [mailto:kzmi@ca2.so-net.ne.jp]
Sent: Wednesday, December 11, 2002 6:08
To: James Developers List
Subject: Re: About fix of cornerstone, FileRepository
On Tue, 10 Dec 2002 14:05:33 -0500
"Noel J. Bergman" <no...@devtech.com> wrote:
> Your contribution is appreciated, but it might be best if you raised this
> issue (and your proposed patch) directly to the Avalon developers on
> avalon-dev@ mailing list. We get the code from that project.
Discussion in Avalon-dev would be good. I think also it would be better
to do refactoring cornerstone's file repository.
But the latest James uses old cornerstone which is not replacable
with the latest one. It means that the repository-bug doesn't
be fixed until we choose the latest cornerstone after heavy work on
James.
You have already wasted over half year from the time Bug#8839 was
reported. It would be better to provide the solution about it.
I think wrapping or modifying old cornerstone.jar is one of the quick
solution.
Regards,
Iwasa Kazmi
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: About fix of cornerstone, FileRepository
Posted by Iwasa Kazmi <kz...@ca2.so-net.ne.jp>.
On Tue, 10 Dec 2002 14:05:33 -0500
"Noel J. Bergman" <no...@devtech.com> wrote:
> Your contribution is appreciated, but it might be best if you raised this
> issue (and your proposed patch) directly to the Avalon developers on
> avalon-dev@ mailing list. We get the code from that project.
Discussion in Avalon-dev would be good. I think also it would be better
to do refactoring cornerstone's file repository.
But the latest James uses old cornerstone which is not replacable
with the latest one. It means that the repository-bug doesn't
be fixed until we choose the latest cornerstone after heavy work on
James.
You have already wasted over half year from the time Bug#8839 was
reported. It would be better to provide the solution about it.
I think wrapping or modifying old cornerstone.jar is one of the quick
solution.
Regards,
Iwasa Kazmi
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: About fix of cornerstone, FileRepository
Posted by "Noel J. Bergman" <no...@devtech.com>.
FYI, I've just re-raised this on avalon-dev@, myself, along with links to
the bug report, the proposed patch, and several prior attempts to discuss
this with the Avalon developers.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: About fix of cornerstone, FileRepository
Posted by "Noel J. Bergman" <no...@devtech.com>.
Iwaza-san,
Your contribution is appreciated, but it might be best if you raised this
issue (and your proposed patch) directly to the Avalon developers on
avalon-dev@ mailing list. We get the code from that project.
--- Noel
-----Original Message-----
From: Iwasa Kazmi [mailto:kzmi@ca2.so-net.ne.jp]
Sent: Tuesday, December 10, 2002 6:53
To: james-dev@jakarta.apache.org
Subject: About fix of cornerstone, FileRepository
Hello,
I cannot use the latest James because of Bug#8839. My PC have
less resources to run the database software, and it is shutdown
at every night.
I have tried two methods to solve Bug#8839.
(a) add wrapper classes of File_Persistent_Object_Repository
and File_Persistent_Stream_Repository. (These classes are
part of cornerstone) See my sample.
These classes replace AbstractFileRepository#initialize().
(b) replace cornerstone.jar with modified version.
I downloaded a snapshot of 2002-06-04 with cvs, changed
AbstractFileRepository#initialize(), and built all.
The patch is cornerstone-kzmi.diff.
(a) seems to work about mail repository with editing config.xml,
but I couldn't find how to replace class for users repository.
(After restarting of James, user listing/counting failed because of
file-repository bug)
Also, these classes depend on the implementations of cornerstone
which is referred.
(b) seems to work well in any repository. Now I'm using James-cvs
with modified cornerstone.jar.
In my changes, repository-id part is removed from filename and
search-pattern. It violates the compatibility of the filename.
But I think such replacement of the cornerstone would be better
for the quality of James, and I would propose to include such improvement in
the next measure release.
Regards,
---
Iwasa Kazmi
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>