Author: jasonw
Date: Wed May 4 23:48:57 2005
New Revision: 168286
URL: http://svn.apache.org/viewcvs?rev=168286&view=rev
Log: (empty)
Added:
james/server/branches/imap-dev/trunk/
- copied from r168285, james/server/trunk/
--
Author: jasonw
Date: Wed May 4 23:46:49 2005
New Revision: 168285
URL: http://svn.apache.org/viewcvs?rev=168285&view=rev
Log:
Removed file/folder
Removed:
james/server/branches/imap-dev/trunk/
-
To unsubscribe, e-mail: [EM
Author: jasonw
Date: Wed May 4 23:44:29 2005
New Revision: 168284
URL: http://svn.apache.org/viewcvs?rev=168284&view=rev
Log:
Copied remotely
Added:
james/server/branches/imap-dev/trunk/
- copied from r168283, james/server/trunk/
--
Author: jasonw
Date: Wed May 4 23:43:23 2005
New Revision: 168283
URL: http://svn.apache.org/viewcvs?rev=168283&view=rev
Log:
Created to hold IMAP development work
Added:
james/server/branches/imap-dev/
-
To unsubscribe, e
Following some additional testing, I have moved the merged code to be the
trunk. Hey, it may not work (or might ;-)), but it is better than the old
trunk.
OK, so everyone should run svn switch to repoint your checkout, or do a
fresh one if you haven't grabed this before.
This should be the new t
Author: noel
Date: Wed May 4 20:40:02 2005
New Revision: 168251
URL: http://svn.apache.org/viewcvs?rev=168251&view=rev
Log:
make merge_v2_and_trunk branch the new trunk
Added:
james/server/trunk/
- copied from r168247, james/server/branches/merge_v2_and_trunk/
Removed:
james/server
Author: noel
Date: Wed May 4 20:15:07 2005
New Revision: 168249
URL: http://svn.apache.org/viewcvs?rev=168249&view=rev
Log:
Mark the initial working merger of v2 and what had been experimental v3 with
Avalon updates. This will be the new mainstream trunk
Added:
james/server/tags/merge_v2_a
Author: noel
Date: Wed May 4 19:52:13 2005
New Revision: 168247
URL: http://svn.apache.org/viewcvs?rev=168247&view=rev
Log:
move pre-merger trunk to a tag under server/. moved to higher level by
accident.
Added:
james/server/tags/pre-v2and3-merger-trunk/
- copied from r168245, james/
Author: noel
Date: Wed May 4 19:38:48 2005
New Revision: 168244
URL: http://svn.apache.org/viewcvs?rev=168244&view=rev
Log:
move the old experimental v3 trunk out of the way, so we can move in the new,
merged, trunk.
Added:
james/tags/pre-v2and3-merger-trunk/
- copied from r168243, ja
Author: noel
Date: Wed May 4 19:27:16 2005
New Revision: 168240
URL: http://svn.apache.org/viewcvs?rev=168240&view=rev
Log:
Just call it 3.0-dev, rather than an alpha release label
Modified:
james/server/branches/merge_v2_and_trunk/default.properties
Modified: james/server/branches/merge_v2
Author: noel
Date: Wed May 4 19:25:55 2005
New Revision: 168239
URL: http://svn.apache.org/viewcvs?rev=168239&view=rev
Log:
Use JavaMail 1.3.2
Modified:
james/server/branches/merge_v2_and_trunk/build.xml
james/server/branches/merge_v2_and_trunk/check-targets.properties
Modified: james/s
Author: noel
Date: Wed May 4 19:23:42 2005
New Revision: 168238
URL: http://svn.apache.org/viewcvs?rev=168238&view=rev
Log:
revision 109187 introduced a bug where if we had a real Return-Path header its
value would not be the first in the String[]. This tries to eliminate that
problem. We sho
Noel J. Bergman wrote:
> > I was thinking more along the lines of having an 'else' like clause
> > but ! support would be a plus too.
>
> OK, guys ... before you go all crazy in the XML ... :-)
>
> Two things:
>
> - Consider a BSF processor for advanced uses. That
> should provide a generic
Jason Webb wrote:
> I need a stable merge point (when Noel says so :)) so I can put in the
IMAP
> branch. If people reckon the current HEAD is good now then I'll branch it
> straight away.
Soon as we get some testing, I'll replace the trunk and also make a tag.
People should not --- and I don't
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]
> Sent: 04 May 2005 16:22
> To: James Developers List
> Subject: Re: JAMES ... now that we (may be) merged, where to?
>
> On 04/05/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>
> > For version 3, then ...
> >
> > -
> > Can you provide more informations on this code?
>
> Look in JIRA for existing patches. We also have some in archives.
Sorry but looking at almost all the latest 100 issues I have not seen
attachments/patches: have I the needed rights to see them?
> Alex Zhukov contributed a lot of great stu
> My priorities are:
> > 1- Full DSN support (SMTPServer, Delivery
> Mailets/Processor, MailImpl)
>
> +1
>
> I assume that you're aware of the existing level of support
> for DSN, right?
> You just want to improve it.
Full and correct DSN support needs more changes.
I wrote a mail few days ago
> Would you mind terribly taking a short pause in your coding,
> and just test?
Sure: I just finished merging the "merge" branch on my local repository.
So I will test my repository, but the changes are not so many so we can
think I'll test the current merge branch.
I submitted most of my changes
> > We also have a lot of existing code that needs to be worked
> > over a bit and merged. Would love to have some folks looking
> > at that, too.
> Can you provide more informations on this code?
Look in JIRA for existing patches. We also have some in archives.
Alex Zhukov contributed a lot o
[
http://issues.apache.org/jira/browse/JAMES-322?page=comments#action_64492 ]
Stefano Bagnara commented on JAMES-322:
---
I worked on this but I need to make changes to a lot of core code to implement
per recipient NOTIFY/ORCPT requests.
Here is an
Stefano Bagnara wrote:
> > If James is to use Mina and is to support TLS, we'll have to
> > use JDK 1.5. Obviously *I* would like to see James
> > incorporate my Mina based SMTP handler.
> It would be cool to use jdk1.5 but I think that jdk1.5 requirement would
be
> a limitation for the spreadin
Stefano,
Would you mind terribly taking a short pause in your coding, and just test?
I am running on very limited time right now, and just want a good sanity
check before I replace the trunk.
--- Noel
-
To unsubscribe,
Mike Heath wrote:
> Noel J. Bergman wrote:
> > I would like to get this version stable, and we can branch it as a JDK
> > 1.3 branch, so that we'll have something good for people still stuck
> > on JDK 1.3. Then we can look at moving mainstream development (trunk)
> > to require JDK 1.4.
> If Ja
> POJO is not high priority for me too.
:-)
My priorities are:
> 1- Full DSN support (SMTPServer, Delivery Mailets/Processor, MailImpl)
+1
I assume that you're aware of the existing level of support for DSN, right?
You just want to improve it.
> 2- RemoteDelivery: reuse/sort connections to the
> We also have a lot of existing code that needs to be worked
> over a bit and merged. Would love to have some folks looking
> at that, too.
Can you provide more informations on this code?
Stefano
-
To unsubscribe, e-mail: [
> If James is to use Mina and is to support TLS, we'll have to
> use JDK 1.5. Obviously *I* would like to see James
> incorporate my Mina based SMTP handler.
It would be cool to use jdk1.5 but I think that jdk1.5 requirement would be
a limitation for the spreading of the new version.
We should
[ http://issues.apache.org/jira/browse/JAMES-356?page=all ]
Stefano Bagnara updated JAMES-356:
--
Attachment: MimeMessageWrapper.java.patch
MimeMessageWrapperTest.java.patch
Here is the patch and the test that shows the bug and the fixed b
ger
> -
>
> Key: JAMES-371
> URL: http://issues.apache.org/jira/browse/JAMES-371
> Project: James
> Type: Improvement
> Components: SpoolManager & Processors
> Versions: 2.2.1
> Environment: James SVN branch truck-merged 2005050
[ http://issues.apache.org/jira/browse/JAMES-360?page=all ]
Stefano Bagnara updated JAMES-360:
--
Attachment: fetchmail-patch-against-mergebranch-20050504.tgz
Here is an updated patch against current (20050504) svn branch trunk-merged.
It supports the
anch truck-merged 20050504.
Reporter: Stefano Bagnara
Priority: Minor
Attachments: JamesSpoolManager.java.patch, LinearProcessor.java.patch
Processor invoke store() on the spool when a message change its state but the
message is still lockend and the notify called by the spool does not work
> > > I'm not a committer
> > Keep working. You could be. :-)
> I'll be, for sure :-)
I hope so. You and others. It has been too long since we've seen such a
group of new, enthusiastic, contributors. Anyone who is interested in
becoming a Committer is enthusiastically welcomed.
So don't get
On Tue, 2005-05-03 at 22:11 -0400, Noel J. Bergman wrote:
> > Were we thinking of requiring JDK 1.4 for James 3.0? If so, we could
> > move to using java.util.regex, eh?
>
> I would like to get this version stable, and we can branch it as a JDK
> 1.3 branch, so that we'll have something good for
> > > High up on my personal priority list is getting the in-process
> > > processor into the system.
>
> > I attached my proposed changes against the "merge" branch.
>
> Nothing attached. Please create a JIRA issue and attach it
> there. :-)
Here:
http://issues.apache.org/jira/browse/JAMES-
> I was thinking more along the lines of having an 'else' like clause
> but ! support would be a plus too.
OK, guys ... before you go all crazy in the XML ... :-)
Two things:
- Consider a BSF processor for advanced uses. That
should provide a generic mechanism for doing as
much advanc
[
http://issues.apache.org/jira/browse/JAMES-369?page=comments#action_64482 ]
Stefano Bagnara commented on JAMES-369:
---
The latest patches are against the trunk-merged branch.
> Always announce AUTH capability to clients
>
[ http://issues.apache.org/jira/browse/JAMES-369?page=all ]
Stefano Bagnara updated JAMES-369:
--
Attachment: SMTPHandler.java.patch
SMTPServer.java.patch
This is my proposal.
This is backward compatible (authRequired=false and authRequire
Danny,
On Wed, 2005-05-04 at 08:50 +0100, Danny Angus wrote:
> - Process to allow mailets to run for a non-match.
>
> Nice idea, perhaps we just need to allow users to invert the sense of the
> matcher with a !
I was thinking more along the lines of having an 'else' like clause
but ! support wo
> > I'm not a committer
>
> Keep working. You could be. :-)
I'll be, for sure :-)
> > There are no many differences with the current 2.2.1-dev to
> switch to
> > a
> 3.0
> > and I think that it is backward compatible with 2.2.x, isn't it?
>
> Well, there are many things that can be done wit
Stefano Bagnara wrote:
> > Well, hopefully I'm not the only one looking at this code.
> I'm applying my local patches and preparing for the tests.
> I'm not a committer
Keep working. You could be. :-)
> IMHO this new "merge" should be soon a 2.3 release,
> the last Avalon-specific.
Agree on
> Well, hopefully I'm not the only one looking at this code.
> :-) But I'll do a few more tests, and if it doesn't go legs
> up, I'll move it to trunk.
I'm applying my local patches and preparing for the tests.
> > the merge [is] the foundation upon which [version 3] will evolve.
>
> For ver
On 04/05/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> For version 3, then ...
>
> - the last Avalon-specific version? POJO is a v4 branch?
Well I actually thought that that would be v3 and we'd move towards it,
3a1 - stable merge
3a2 - pojo
get it?
Perhaps its too complicated and we sh
Danny Angus wrote:
> > If this merged code works, what do we want to do about a release?
> Well my +1 would be forthcoming to a proposal to smoke test and
> release it as the first 3 alpha.
Well, hopefully I'm not the only one looking at this code. :-) But I'll do
a few more tests, and if it d
My man! I'm writing portal providers as we speak.
Be sure to look out for a 40+ year old (with a beery smile) in the audience ;-)
On 04/05/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> > Unless you're likely to be going to ApacheConEU?
>
> http://www.apachecon.com/html/session-popup.html?id=13
Stefano Bagnara wrote:
> > High up on my personal priority list is getting the
> > in-process processor into the system.
> I attached my proposed changes against the "merge" branch.
Nothing attached. Please create a JIRA issue and attach it there. :-)
> I removed the spool handling from the
On 04/05/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> If this merged code works, what do we want to do about a release?
Well my +1 would be forthcoming to a proposal to smoke test and
release it as the first 3 alpha.
If we "advertise" it carefully it will be clear that it is an unstable
rele
> High up on my personal priority list is getting the
> in-process processor into the system.
I attached my proposed changes against the "merge" branch.
I removed the spool handling from the LinearProcessor and changed the
spoolmanager processing so that it take a mail from it's first processor
On 04/05/05, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Danny wrote:
> But have we tested and verified that capability, specifically?
No but we can reason that James is compliant based upon the design of
the SMTP handler and the fact that the SMTP handler works as designed.
d.
---
Danny wrote:
> Mike Heath wrote:
> > The James EHLO response doesn't include the keyword PIPELINING per RFC
> > 1854 even though my understanding of the code would indicate that James
> > does indeed support pipelining.
> I think James does indeed support pipelining
But have we tested and verifie
Danny wrote good things on services and location:
> 1/ they don't need to be exposed anywhere if we spec them as
>locatable and optional,
> The service locator mechanism must be clearly spec'ed so that all
> those deployemnts which do require them can reliably find them.
> 2/ The concepts mu
> Unless you're likely to be going to ApacheConEU?
http://www.apachecon.com/html/session-popup.html?id=1357
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I think James does indeed support pipelining, however what we're bad
at doing is advertising the ESMTP extensions we support.
Submit a patch or raise this enhancement in Jira.
On 04/05/05, Mike Heath <[EMAIL PROTECTED]> wrote:
> The James EHLO response doesn't include the keyword PIPELINING per RF
The James EHLO response doesn't include the keyword PIPELINING per RFC
1854 even though my understanding of the code would indicate that James
does indeed support pipelining. Is there something that I'm missing?
-Mike
-
To uns
> Not sure if the user and store interfaces should ever be in that set,
> though, since there are entire ranges of mailet containers that don't
need
> to provide them. Those are services, which could be discoverable.
Mixing two issues.
1/ they don't need to be exposed anywhere if we spec them
> > OK, I can't say that it runs (I haven't tried, yet), but it does build.
> Hip, hip, hooray!
+1.
Well done Noel. Your hard work has not gone unnoticed.
Unfortunately in time honoured fashion it will probably go unrewarded. ;-)
Unless you're likely to be going to ApacheConEU?
In which case I
Mike,
- Mailet staging -
- Mailets as deployable units -
- Multiple mailets per matcher.
These three have been on the "list" for ages, welcome to our vision ;-)
- Process to allow mailets to run for a non-match.
Nice idea, perhaps we just need to allow users to invert the sense of the
matche
Serge Knystautas wrote:
>
One thing that always bug me about webapps is how they restart. Why
should there be any downtime? I'm going to have a new classloader and
fully initialize it... don't tear down the first instance until the
second is fully initialized, then cutover and hand new connect
56 matches
Mail list logo
