Hi,
be read by other toosl, I don't think that there is a place to preserve
the
meta-data from the Mail object (but we can check).
As far as Maildir goes, there isn't, from what I can tell.
make it a requirement to support special stores for spam and error that
preserve the associated mail
make it a requirement to support special stores for spam and error that
preserve the associated mail objects, I think that'll be OK.
2. We could retain/enhance the MailRepository interface and write an
implementation which wraps around JavaMail stores?
As Serge pointed out, to do IMAP
I already run using -server as it has a more reliable gc pattern.
However, I still get a leak over time. The GC log is just a method of
seeing how big it is...
After a while the heap will grow it it's maximum (128mb in this case)
James will then stop processing email (not BUT receiving it). This
Noel J. Bergman wrote, On 04/02/2003 19.33:
Note: sorry for the OT, but it's really interesting :-)
Especially since Andy just proposed using the maven repository as the
primary means for distributing all ASF Java technologies. I think I'll let
other people worry about that suggestion.
Thanks for the response Noel. I'm coming around to the idea; it seems like
you've put a lot of thought into this.
I guess my main worry is using JNDI where it's not a valid match to
requirements. I remember a discussion on ant-dev where the merits of using
JNDI for a VFS interface were
Sergei
2. We could retain/enhance the MailRepository interface and write an
implementation which wraps around
JavaMail stores? This would give us access to special stores
and JavaMail
stores but JM stores would not persist the message meta-data and we would
not be adopting a new standard
I would like to know whether this would work..
re-write Mail as public abstract class Mail extends MimeMessage
then when we write repository implementations we can pass our Mails, and any
repositories we have written can test and cast the messages back to Mails and
serialise the metadata.
On Tue, 4 Feb 2003 01:51, Noel J. Bergman wrote:
Yes, the proposal is to use the JavaMail interfaces instead of the
MailRepository interfaces, which were not in Mailet API until a few weeks
ago, as you know, and would be rolled out. However, you appear to be
missing a key point.
I like the
Hi Danny,
re-write Mail as public abstract class Mail extends MimeMessage
Yeah, how does this affect serialization and are we currently ever
serializing a Mail object?
Serge
- Original Message -
From: Danny Angus [EMAIL PROTECTED]
To: James Developers List [EMAIL PROTECTED]
Sent:
Hi Danny,
re-write Mail as public abstract class Mail extends MimeMessage
Yeah, how does this affect serialization and are we currently ever
serializing a Mail object?
Serge
- Original Message -
From: Danny Angus [EMAIL PROTECTED]
To: James Developers List [EMAIL PROTECTED]
Sent:
Guys, specially Serge,
please examine this patch and tell me why I shouldn't commit it.
The symptom: setting headers on a MimeMessageWrapper object appeared to cause the
message-id to change
The problem: MimeMessageWrapper was calling saveChanges() in writeTo(), and
saveChanges() sets a
Absolutely!! Please commit it!
We rely on the message-id being correct (i.e. the original message).
Therefore when saveChanges() updates it, you don't have the original
message anymore. This makes threading the message (if it's passed on) a
lot more difficult.
-- Jason
-Original
The problem: MimeMessageWrapper was calling saveChanges() in writeTo(),
and saveChanges() sets a new Message_Id every time, regardless.
please examine this patch and tell me why I shouldn't commit it.
Does it break any existing code? If we don't call saveChanges(), changes to the
headers
I would like to know whether this would work..
re-write Mail as public abstract class Mail extends MimeMessage
That doesn't appear to be necessary, nor solve the problem, and keeps Mail a
heavierweight object than it needs to be, which will slow down spool processing.
But let's asssume, for
The following seems to provide user control over Message-ID generation:
http://www.magelang.com/faq/view.jsp?EID=516514
Yes it does Noel, but it won't work if writeTo() calls saveChanges() AND we need to
create message id's where noe exist, OR we want ot create new message ID's for
Thanks for your comments in
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770. I have done some
cleanup of the exception handling, primarily where it bit me, but James
could use a thorough review and overhaul of how exceptions are handled.
I invite you to join james-dev@, and help out with
Few questions regd portability:
Would James ever need to have a non Java version ?
Should it be easy to port mailets to non java solutions ?
At present James only runs on Java (hence the J in name) but Avalon, Log4J
and a lot of other Apache projects have been ported.
Do you think this would be
noel2003/02/05 21:24:18
Added: src/java/org/apache/james/transport/matchers Tag:
branch_2_1_fcs FileRegexMatcher.java
GenericRegexMatcher.java
Log:
experimental regex matchers at request of users
Revision ChangesPath
noel2003/02/05 21:25:29
Modified:src/java/org/apache/james/transport/matchers Tag:
branch_2_1_fcs NESSpamCheck.java
Log:
refactored as subclass of generic regex matcher
Revision ChangesPath
No revision
No
noel2003/02/05 21:26:38
Modified:src/xdocs Tag: branch_2_1_fcs FAQ.xml
Log:
updated to refer to phoenix wrapper for windows services
Revision ChangesPath
No revision
No revision
1.24.4.1 +1 -40
noel2003/02/05 21:27:05
Modified:src/xdocs Tag: branch_2_1_fcs changelog.xml
Log:
updated for v2.1.1a6
Revision ChangesPath
No revision
No revision
1.11.4.2 +3 -1 jakarta-james/src/xdocs/changelog.xml
noel2003/02/05 22:00:52
Modified:src/xdocs changelog.xml
Log:
updated for v2.1.1a6
Revision ChangesPath
1.14 +3 -1 jakarta-james/src/xdocs/changelog.xml
Index: changelog.xml
===
RCS
noel2003/02/05 22:01:05
Modified:src/xdocs FAQ.xml
Log:
updated to refer to phoenix wrapper for windows services
Revision ChangesPath
1.25 +1 -40 jakarta-james/src/xdocs/FAQ.xml
Index: FAQ.xml
noel2003/02/05 22:06:45
Added: src/java/org/apache/james/transport/matchers
FileRegexMatcher.java GenericRegexMatcher.java
Log:
experimental regex matchers at request of users
Revision ChangesPath
1.2 +44 -0
noel2003/02/05 22:06:54
Modified:src/java/org/apache/james/transport/matchers
NESSpamCheck.java
Log:
refactored as subclass of generic regex matcher
Revision ChangesPath
1.7 +46 -81
noel2003/02/05 22:14:44
Modified:src/xdocs Tag: branch_2_1_fcs changelog.xml
Log:
added crossposting fix
Revision ChangesPath
No revision
No revision
1.11.4.3 +1 -0 jakarta-james/src/xdocs/changelog.xml
Hi,
I believe that enough of a consensus has been reached that we can safely
say that JNDI support will be including in an upcoming James release.
The details of exactly what it will be used for (and how) are still to
be finalised.
I am beginning work on providing a useable JNDI facility,
noel2003/02/05 22:25:59
Modified:src/java/org/apache/james/fetchmail FetchMail.java
FetchScheduler.java FetchScheduler.xinfo
ReaderInputStream.java
Log:
crlf conversion
Revision ChangesPath
1.2 +367 -367
Hi again,
For the moment, I am putting my code in org.apache.james.jndi. Before I
get too far down the track, we will need to agree whether this is
appropriate. One thing to consider is whether or not this work should
be specific to James, or whether it should be a commons package, or even
noel2003/02/05 22:31:51
Added: www/mailet overview-frame.html overview-summary.html
Log:
generated docs
Revision ChangesPath
1.1 jakarta-james/www/mailet/overview-frame.html
Index: overview-frame.html
noel2003/02/05 22:33:15
jakarta-james/www/mailet/org/apache/mailet/dates - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
noel2003/02/05 22:42:02
jakarta-james/www/javadocs/org/apache/mailet/dates - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
noel2003/02/05 22:42:08
jakarta-james/www/javadocs/org/apache/mailet/dates/class-use - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
noel2003/02/05 22:43:02
Added: www/javadocs/org/apache/mailet/dates/class-use
RFC2980DateFormat.html RFC822DateFormat.html
RFC977DateFormat.html SimplifiedDateFormat.html
SynchronizedDateFormat.html
Log:
- Original Message -
From: Aaron Knauf [EMAIL PROTECTED]
... we will need to agree on the correct way
to establish this dependency.
Two things seem obvious to me here:
1. We don't want to depend on the whole tomcat project just to get
the Naming stuff.
It may be a good
I just posted v2.1.1a6 to the nightly build directories. If this looks
good, I'd like to get a vote to release it as v2.1.1. The test build
includes logkit v1.2 (not in CVS), but that won't go out unless Avalon votes
to release it. I expect that to occur by the weekend. Logkit v1.2 fixes
the
36 matches
Mail list logo
