Noel J. Bergman wrote:
*** ONE TIME OFFER: Because of the recent Internet worm, the ASF has
installed new filters for the mail server. One of the victims is ZIP
format, which is currently banned as a virus payload. JAR and TAR files are
accepted. But we should also be able to accept patch and ja
This is a bit long, so let me start right up front and ask whom has code
that they would like considered for the next James release?
Vincenzo: S/MIME code?
Bayesian code?
Danny:Bayesian code?
Andreas Goggerle: DSNBounce mailet?
Chris Hane: Mail
Noel J. Bergman wrote:
> I just finished applying the Apache Software License version
> 2.0 to the MAIN
> branch. We'll still need to do a notice file, but the .java
> files have been
> updated. Please report any problems if you spot them.
Do you have a wizzy quick way of doing this or is it jus
Serge Knystautas wrote:
>
> Steve Brewin wrote:
> >>We need to sort out releases quick... to mark this as fixed
> >>for release
> >>2.1, something that went out over a year ago, won't really help us.
> >
> > Oops, you are right! I was getting confused between
> branches and releases. I
> > wonder i
Steve Brewin wrote:
We need to sort out releases quick... to mark this as fixed
for release
2.1, something that went out over a year ago, won't really help us.
Oops, you are right! I was getting confused between branches and releases. I
wonder if we can close releases in Jira so its not possible to
Serge Knystautas wrote:
>
>
> We need to sort out releases quick... to mark this as fixed
> for release
> 2.1, something that went out over a year ago, won't really help us.
Oops, you are right! I was getting confused between branches and releases. I
wonder if we can close releases in Jira so its
We need to sort out releases quick... to mark this as fixed for release
2.1, something that went out over a year ago, won't really help us.
What's the next release we're planning? 2.2a17? We should create
something as the next release (even if we just name it release "Next"),
and mark this as
As far as I can see the only way is to introduce a new JamesConnectionManager
interface (extending ConnectionManager) which adds the methods we need.
Make SimpleConnectionManager implement that and finally use the new interface
in assembly.xml.
Then in AbstractJamesService we can use instanceof
sbrewin 2004/02/09 08:20:45
Modified:src/xdocs Tag: branch_2_1_fcs provided_mailets_2_1.xml
Log:
Corrected erroneous end tag which was causing a build failure.
Revision ChangesPath
No revision
No revision
1.5.4.7 +1 -1 james
sbrewin 2004/02/09 08:15:45
Modified:src/java/org/apache/james/fetchmail Tag: branch_2_1_fcs
Account.java FetchMail.java
ParsedConfiguration.java MessageProcessor.java
FolderProcessor.java ProcessorAbstract.java
> > Looks to me that if the connection manager is not our
> > SimpleConnectionManager, we won't use the service-specific setting.
> the piece of offending code in AbstractJamesService is:
> if (connectionManager instanceof SimpleConnectionManager)
> This is never true, as connectionManager is an
> But I do agree that we should be really careful what goes into the Mailet
> API, and keep it focused on what should be in a portable Mailet
container,
> not just James. Since Danny has probably given the most thought to those
> issues, I hope that he'll aggressively police keeping the Mailet
> There are also lots of ideas for JNDI and James in the archives from
> discussions last year.
I remember, it was that debate which swung me in favour of JNDI, so much so
that I'm prepared to both do the work and evangelise it :-)
Don't ever suggest I'm *always* grumpy and intransigent again
> Would this be a good time to move the mailet API into it's own
> repository, or at least separate it in CVS more distinctly? Heck, once
> we work out any issues with it, stick it in SVN and just have
> james-server work off of a jar. :)
+1 great idea. But lets not increase the number of t
14 matches
Mail list logo
