[jira] Updated: (JAMES-529) Add a GenericAddFooter for use in AddFooter and CommandListservFooter
[ http://issues.apache.org/jira/browse/JAMES-529?page=all ] Norman Maurer updated JAMES-529: Fix Version: 2.3.0 > Add a GenericAddFooter for use in AddFooter and CommandListservFooter > - > > Key: JAMES-529 > URL: http://issues.apache.org/jira/browse/JAMES-529 > Project: James > Type: Task > Reporter: Norman Maurer > Assignee: Norman Maurer > Fix For: 2.3.0, 2.4.0 > > We should build a GenericAddFooter class which should be used in AddFooter > and CommandListservFooter. So we can remove duplicate code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r413813 - in /james/server/branches/v2.3/src/java/org/apache/james/transport/mailets: AbstractAddFooter.java AddFooter.java CommandListservFooter.java
Author: norman
Date: Mon Jun 12 23:09:36 2006
New Revision: 413813
URL: http://svn.apache.org/viewvc?rev=413813&view=rev
Log:
Add an abstract class for adding a Footer. Change AddFooter and
CommandListservFooter to extend this class. See JAMES-529
Added:
james/server/branches/v2.3/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java
- copied unchanged from r413624,
james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java
Modified:
james/server/branches/v2.3/src/java/org/apache/james/transport/mailets/AddFooter.java
james/server/branches/v2.3/src/java/org/apache/james/transport/mailets/CommandListservFooter.java
Modified:
james/server/branches/v2.3/src/java/org/apache/james/transport/mailets/AddFooter.java
URL:
http://svn.apache.org/viewvc/james/server/branches/v2.3/src/java/org/apache/james/transport/mailets/AddFooter.java?rev=413813&r1=413812&r2=413813&view=diff
==
---
james/server/branches/v2.3/src/java/org/apache/james/transport/mailets/AddFooter.java
(original)
+++
james/server/branches/v2.3/src/java/org/apache/james/transport/mailets/AddFooter.java
Mon Jun 12 23:09:36 2006
@@ -17,25 +17,14 @@
package org.apache.james.transport.mailets;
-import org.apache.mailet.GenericMailet;
-import org.apache.mailet.Mail;
-import org.apache.mailet.RFC2822Headers;
-
import javax.mail.MessagingException;
-import javax.mail.internet.MimeBodyPart;
-import javax.mail.internet.MimeMessage;
-import javax.mail.internet.MimeMultipart;
-import javax.mail.internet.MimePart;
-
-import java.io.IOException;
-import java.io.UnsupportedEncodingException;
import java.util.StringTokenizer;
/**
* This mailet will attach text to the end of the message (like a footer).
Right
* now it only supports simple messages without multiple parts.
*/
-public class AddFooter extends GenericMailet {
+public class AddFooter extends AbstractAddFooter {
/**
* This is the plain text version of the footer we are going to add
@@ -50,59 +39,6 @@
}
/**
- * Takes the message and attaches a footer message to it. Right now, it
only
- * supports simple messages. Needs to have additions to make it support
- * messages with alternate content types or with attachments.
- *
- * @param mail the mail being processed
- *
- * @throws MessagingException if an error arises during message processing
- */
-public void service(Mail mail) throws MessagingException {
-try {
-MimeMessage message = mail.getMessage();
-//log("Trying to add footer to mail " + mail.getName());
-if (attachFooter(message)) {
-message.saveChanges();
-//log("Message after saving: " +
message.getContent().toString());
-/*
-java.io.ByteArrayOutputStream bodyOs = new
java.io.ByteArrayOutputStream(512);
-java.io.OutputStream bos;
-java.io.InputStream bis;
-try {
-bis = message.getRawInputStream();
-bos = bodyOs;
-log("Using getRawInputStream()");
-} catch(javax.mail.MessagingException me) {
-bos = javax.mail.internet.MimeUtility.encode(bodyOs,
message.getEncoding());
-bis = message.getInputStream();
-log("Using getInputStream()");
-}
-
-try {
-byte[] block = new byte[1024];
-int read = 0;
-while ((read = bis.read(block)) > -1) {
-bos.write(block, 0, read);
-}
-bos.flush();
-}
-finally {
-org.apache.avalon.excalibur.io.IOUtil.shutdownStream(bis);
-}
-log("Message from stream: " + bodyOs.toString());
-*/
-} else {
-log("Unable to add footer to mail " + mail.getName());
-}
-} catch (UnsupportedEncodingException e) {
-log("UnsupportedEncoding Unable to add footer to mail " +
mail.getName());
-} catch (IOException ioe) {
-throw new MessagingException("Could not read message", ioe);
-}
-}
-
-/**
* This is exposed as a method for easy subclassing to provide alternate
ways
* to get the footer text.
*
@@ -144,105 +80,5 @@
*/
public String getMailetInfo() {
return "AddFooter Mailet";
-}
-
-/**
- * Prepends the content of the MimePart as text to the existing footer
- *
- * @param part the MimePart to attach
- *
- * @throws MessagingException
- * @throws IOException
- */
-protected void addToText(MimePart part) throws MessagingException,
IOException {
-//
[jira] Commented: (JAMES-502) IMAP support
[ http://issues.apache.org/jira/browse/JAMES-502?page=comments#action_12415934 ] Joachim Draeger commented on JAMES-502: --- 2006-06-13 Hi everybody, after a lot of javamaildir and JavaMailStoreMailRepository i found some time for IMAP again. To safely share the JavaMail Store between MailRepository and possibly multiple instances of IMAP i wrote a StoreGateKeeper in additional to the FolderGateKeeper to care for caching and opening/closing Folders. It looks a bit complicated because everything goes through a few wrappers but it makes it possible to keep parts separated. The reason is that javamaildir allows access by multiple threads but not at multiple instances of one Folder. Additionally a Folder has to be closed after a session to write Flags. To say it again: There is no strong dependency to JavaMail Store or javamaildir. I've implemented two existing interfaces: ImapMailbox and ImapHost. This time I followed a bit the TDD and exploratory testing. It really sucks to always build a jar launch James start Thunderbird and search through the logs until you find an exception or the right debug message. After writing a few very simple stubs/mocks I could start the server directly through a static void main! (see test org.apache.james.imapserver.util.ImapServerLauncher) Just create a tcp directory choose run from eclipse and have fun. Or just run it in the debugger. The traffic gets logged into tcp. In org.apache.james.imapserver.handler.session.SessionTest I'm just using a ByteArrayStream pair and process it via ImapRequestHandler.handleRequest(); Using debugger is very useful here too. I preferred first writing my own tests (exploratory) in favor of the existing original ones. But now I understand them much better and I'm sure many of them could be reanimated. For two reasons I decided to setup a public svn repository. 1. Putting out a "release" takes much time, even it is only a probosal. 2. I hope more people will join now But of course I would like to see Imap server playing in the james sandbox soon. :-) http://svn.joachim-draeger.de/repos/james/ It contains the latest (my) versions of javamaildir, javamailstore-mailrepository and imap. The latest versions of all three are needed at the moment. But they should be easy to build. Just download a few libs and use ant. Or just make a few clicks in sure IDE and wire the source folders together. I had to block the directories including mixed licensed jars for known reasons. javamaildir just needs junit,activation and javamail. javamailstore-mailrepository is well documentated. :-) imap needs log4j, junit, jmock 1.1.0RC1, commons-io and many jars from the james lib directory. I hope to have a convenient build like in javamailstore-mailrepositroy soon. Please ask if you have any questions. To get startet in IMAP I found this document very useful: http://www.cs.nyu.edu/artg/internet/Spring2003/assignments/rfc2060_with_changes-04-23.pdf (with highlighted important parts and comments) At the moment I will concentrate on Thunderbird 1.5 as client. For a reference it is quite helpful to watch "real life" imap sessions with a packet sniffer like ethereal. As a reference server I prefer courier. If you don't have access to a suitable account I could create one for you at my server. The next tasks will be: 1. creating a build script 2. reanimate existing tests 3. maybe some fancy UML 4. bringing more commands to life 5. think of a James Imap compatible MessageRepository I'm looking forward for your input and questions! :-) Joachim > IMAP support > > > Key: JAMES-502 > URL: http://issues.apache.org/jira/browse/JAMES-502 > Project: James > Type: New Feature > Components: IMAPServer > Reporter: Stefano Bagnara > Fix For: 3.0 > Attachments: james-imap2-proposal-extended1.zip, james-imap2-proposal.zip > > James needs a working IMAP implementations. This is just a container for the > IMAP efforts and updates. > Many times in the list people ask the current status, the missing steps, and > more. We should add subtasks to this issue to clear up things. > If you're willing to help with IMAP support for James please read mailing > list archives and this issue history and discuss in the list what you're > willing to do. > I (Stefano) will be happy to help for everything related the James/Avalon > integration and the correct service interactions, but I don't know anything > about the IMAP protocol itself. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECT
RE: Proposal: new approach to spooling
Noel J. Bergman wrote: > > Steve Brewin wrote: > > > I think there is a lot of merit in coming up with a new > queueing mechanism > > > we should explain the benefits any proposed change is > seeking to achieve. > > Considering the amount of available "free time", there had > better be some > serious benefits, no? ;-) And from what you have written there are many. I'll take the time it deserves to digest all you have provided in this and your earlier post. For now, wow! You really have put meat on the bones of the proposal. It must have taken a fair amount of your "free time". Thanks for this. -- Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r413624 - in/james/server/trunk/src/java/org/apache/james/transport/mailets:AbstractAddFooter.java AddFooter.java CommandListservFooter.java
I reviewed the recent changes and your proposed change. I use CommandListservFooter in my deployment, so I'll be able to give it a workout, and should notice any issues. I'm OK for you to copy it to the branch. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-449) RemoteAddr and RemoteHost incorrectly set
[ http://issues.apache.org/jira/browse/JAMES-449?page=comments#action_12415892 ] Norman Maurer commented on JAMES-449: - Noel what about this ? Is it still there ? Can you give more infos ? > RemoteAddr and RemoteHost incorrectly set > - > > Key: JAMES-449 > URL: http://issues.apache.org/jira/browse/JAMES-449 > Project: James > Type: Bug > Components: Matchers/Mailets (bundled) > Reporter: Noel J. Bergman > > At some point -- I suspect LocalDelivery, but haven't checked -- the > remoteaddr and remotehost fields are being set to localhost instead of the > correct values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal: new approach to spooling
Stefano Bagnara wrote: > 1) What are the benefits of inverting the queue <=> processor relation? See my replies to Steve. I'm after several capabilities, and did consider several alternative syntactic approaches, but only care about relative ease of expression and functional capability. > 2) Are you willing to actually implement this or is this just a discussion? I'd expect to work on it. I'd also expect that more than one person would work on different aspects of it. > I'm +1 to experiment and refactor the code to add some of the features > you describe here (e.g: fallthrough, transactions) as a progressive > evolution. We already have fallthrough, but adding that as an attribute would be a simple and nice enhancement. Transactions are rather more work. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal: new approach to spooling
Steve Brewin wrote: > We should define an interface that meets our requirements for dispatching > work, most likely a subset of the JMS APIs. Implementations of which may > use any SOA style service, be it JMS, WebServices, whatever. We can, but I assert that although we can change the Mailet API to look more like JMS, the put operation is already present as Mail.setState, and the get/onMessage is exposed as a service method. > One thing we can't be assured off is that the service can always consume the > work, so we have to have a clear contract for this. Probably no more than a > set of specialized Exceptions? Seems likely, yes. > > - Each processor is a transaction. What this means > > is that we can try to wrap a global transaction > > around behavior within the processor. This will > > have some impact on Mailets, too > I'ld suggest using javax transactions. I expect so, yes. I don't have any experience with is XA implementation in Java, other than using existing implementations, but the goal ought to be for our queue managers and other applicable resources to play nicely in the XA scenario. > I would not define interfaces for the queue manager and processor, > but rather define semantics and responsibilities. > Lost me here. I'm not sure why we can't define interfaces for the > things that we talk to and why we wouldn't want to. Perhaps you > can elaborate? Hmmm ... perhaps it wasn't clear that I was separating what JAMES needs to define from what I see as at least potentially generic in the Mailet domain. For JAMES, I would expect us to have specific interfaces, but I would not impose them on the overall concepts, in order to leave maximum flexibility to authors of independent Mailet servers. I view the requirements as: - What does the Mailet API need from the environment? The mailet container is require to establish that, since it invokes the Mailet API. For JAMES, the Mailet container is the processor. - What does the Mailet container require from the environment? In the proposed approach, the queue manager is responsible to establish that, since the queue manager invokes the processor. I can argue that we don't need to define the mailet container interface, and that the processor interface can be JAMES-specific. However, I did comment incorrectly earlier with the MDB example, which should not have been a processor, and would like to define a processor interface, even as a separate package, in order to open the door to sharing processor implementations across server implementations. Again, one can imagine many ways to configure and invoke mailets, so I sort of view this as akin to Pluto. You can host the Mailet API however you want, but we can provide you with pre-written containers to plug into your messaging engine. - What does the queue manager require from the enviroment? Even if we provide pre-written containers, I feel that we can leave maximum flexibility by defining the responsibilities of a queue manager without requiring a specific queue manager interface. Certainly, for JAMES, we will have interfaces for processors and queue managers. I just don't feel that there is a *necessary* one in the generic case, even to use our pre-written processors. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Proposal: new approach to spooling
Steve Brewin wrote:
> I think there is a lot of merit in coming up with a new queueing mechanism
> we should explain the benefits any proposed change is seeking to achieve.
Considering the amount of available "free time", there had better be some
serious benefits, no? ;-)
> might these be support for distributed operation
Yes. Absolutely.
> integration into other service oriented architectures?
Somewhat. Possibly not arguable as a primary goal. And we may also foster
the use of the Mailet API well beyond JAMES.
> > Concepts:
> > - Each processor is a named queue entry.
Our core architecture for the mailet pipeline would be message-based,
reusing well-established patterns from distributed queuing platforms, such
as MQ, JMS and others. The use of a named queue is basically what we have
today: each processor is named. I also assert that processor names are
locally scoped references, disassociated from real resources. So if we have
a distributed scenario, we may end up with something like:
jms/myQF
jms/myQ
jdbc/myDS
mQueue
...
Those are just quick and not necessarily complete examples, but basically
they define local processors so that we can do a put operation locally
without having to know the network topology, nor the real queue resource
name, and the local processor is just there to define in one place the queue
technology and address required. Notice how we can mix and match entirely
different queuing technologies, since the queue manager is responsible for
providing put and get operations for both the processor (consumer) and any
senders. The QAlias class, in this case, wouldn't do much, but it would
complain if there were a pipeline actually defined here. The final example
defines a processor that is locally addressed, processes locally, but might
also be remotely addressable. For that matter, any of the QAlias examples
could be defining an alias to that processor, since we don't know from this
textual context what context.lookup("queue/myRoot") will instantiate.
And a cool thing is that in an incoming message protocol handler, we could
have:
and that would define the root processor for that particular message
handler. You could have separate root servers for SMTP vs SMTPS, for
example. This begs the question of what to do about
MailetContext.sendMail() within the pipeline, which starts at the implicit
root processor. I see that as implementation-specific, and somewhat ripe
for discussion.
This is a bit primative, albeit not dissimilar from MQSeries. We can
improve upon it, e.g., by looking up queue managers -- implementation and
all -- from JNDI as shown, but I am trying to not assume that every
implementation will have JNDI or JMS or JDBC pervasive throughout the
system.
> > - A queue entry would normally contain a JAMES Mail
> > object.
No real change from what we have today. Just identifying the players in the
architecture.
> - Each processor [defines] a transaction.
This is a key concept. We are supposed to behave this way, but we have
failure scenarios today because we do not have transactional behavior in
JAMES. So I'm defining the transaction boundary. The processor is the
transaction. Either everything completes successfully or nothing does. In
the event of a failure, the get operation rolls back so that the message is
available to be processed again.
> - Each processor is associated with a queue manager
> and, optionally, a retry schedule.
This takes what we had to do in RemoteDelivery, and generalizes it. For
example, what happens if [clamd | DNS | spamd] is not available? We can
queue up and wait for the service to become available. Perhaps we might
want to add something to allow notification (think queue events for those of
you who know MQ), but the real issue is that every processor can be made
more reliable.
I am a bit surprised that this is an area that Stefano asked about, because
one of the earliest messages from him that I recall was about wanting
multiple spoolers because he wanted finer grained control over threads
available to specific processors. Perhaps he is wondering why I didn't
express things as:
...
For one thing, the processor is more the mental focus for an administrator.
But in addition, the spoolmanager, at this level of discourse, would not
have multiple queues (and thus not multiple processors), unless we did
something like:
...
...
Which gets us back to what I expressed. Recalling that processors are the
named targets, and therefore are what is logically attached to a queue, and
that the queue manager is the entity bridging the processor and the queue,
it seems to make the most sense to describe it as I have in the proposal.
But that's why we post these things for discussion.
And, yes, the queue manager would continue to be
[jira] Created: (JAMES-530) Add more spool manage commands to RemoteManager
Add more spool manage commands to RemoteManager --- Key: JAMES-530 URL: http://issues.apache.org/jira/browse/JAMES-530 Project: James Type: New Feature Components: Remote Manager Reporter: Norman Maurer Assigned to: Norman Maurer We should add more commands to handle the spool from RemoteManger. For example something like : -remove all mail which has subject = "test" -remove all mail which has sender = xyz; . Maybe also regex etc. Thats very usefull if your queue was grow up with spam bounces which can not delivered etc.. We had such a case in the lastyear where our queue was about 1million emails! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r413653 - in /james/server/trunk/src/java/org/apache/james/transport/matchers: AttachmentFileNameIs.java IsInWhiteList.java
Author: norman Date: Mon Jun 12 06:38:24 2006 New Revision: 413653 URL: http://svn.apache.org/viewvc?rev=413653&view=rev Log: -Remove not needed imports Modified: james/server/trunk/src/java/org/apache/james/transport/matchers/AttachmentFileNameIs.java james/server/trunk/src/java/org/apache/james/transport/matchers/IsInWhiteList.java Modified: james/server/trunk/src/java/org/apache/james/transport/matchers/AttachmentFileNameIs.java URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/transport/matchers/AttachmentFileNameIs.java?rev=413653&r1=413652&r2=413653&view=diff == --- james/server/trunk/src/java/org/apache/james/transport/matchers/AttachmentFileNameIs.java (original) +++ james/server/trunk/src/java/org/apache/james/transport/matchers/AttachmentFileNameIs.java Mon Jun 12 06:38:24 2006 @@ -27,12 +27,10 @@ import java.io.IOException; import java.util.ArrayList; import java.util.Collection; -import java.util.Iterator; import java.util.StringTokenizer; import java.util.Locale; import java.util.zip.ZipInputStream; import java.util.zip.ZipEntry; -import java.io.InputStream; import java.io.UnsupportedEncodingException; Modified: james/server/trunk/src/java/org/apache/james/transport/matchers/IsInWhiteList.java URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/transport/matchers/IsInWhiteList.java?rev=413653&r1=413652&r2=413653&view=diff == --- james/server/trunk/src/java/org/apache/james/transport/matchers/IsInWhiteList.java (original) +++ james/server/trunk/src/java/org/apache/james/transport/matchers/IsInWhiteList.java Mon Jun 12 06:38:24 2006 @@ -24,19 +24,16 @@ import org.apache.avalon.framework.service.*; import org.apache.james.*; -import org.apache.james.core.*; import org.apache.james.services.*; import org.apache.james.util.*; import javax.mail.*; -import javax.mail.internet.*; import java.util.Collection; import java.util.StringTokenizer; import java.sql.*; import java.util.*; -import java.text.*; import java.io.*; /** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r413624 - in /james/server/trunk/src/java/org/apache/james/transport/mailets: AbstractAddFooter.java AddFooter.java CommandListservFooter.java
I whould like to put it in 2.3 branch also cause we have fixed some bugs
in the AddFooter mailet (which i used as template for the abstract
class) before which never was fixed ( as i know) in
CommandListservFooter. Anyone see problems with this code ?
bye
Norman
Am Montag, den 12.06.2006, 10:20 + schrieb [EMAIL PROTECTED]:
> Author: norman
> Date: Mon Jun 12 03:19:59 2006
> New Revision: 413624
>
> URL: http://svn.apache.org/viewvc?rev=413624&view=rev
> Log:
> Add an abstract class for adding a Footer. Change AddFooter and
> CommandListservFooter to extend this class
>
> Added:
>
> james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java
> Modified:
>
> james/server/trunk/src/java/org/apache/james/transport/mailets/AddFooter.java
>
> james/server/trunk/src/java/org/apache/james/transport/mailets/CommandListservFooter.java
>
> Added:
> james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java
> URL:
> http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java?rev=413624&view=auto
> ==
> ---
> james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java
> (added)
> +++
> james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java
> Mon Jun 12 03:19:59 2006
> @@ -0,0 +1,189 @@
> +/***
> + * Copyright (c) 2006 The Apache Software Foundation. *
> + * All rights reserved.*
> + * --- *
> + * Licensed under the Apache License, Version 2.0 (the "License"); you *
> + * may not use this file except in compliance with the License. You*
> + * may obtain a copy of the License at:*
> + * *
> + * http://www.apache.org/licenses/LICENSE-2.0 *
> + * *
> + * Unless required by applicable law or agreed to in writing, software *
> + * distributed under the License is distributed on an "AS IS" BASIS, *
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or *
> + * implied. See the License for the specific language governing *
> + * permissions and limitations under the License. *
> + ***/
> +
> +package org.apache.james.transport.mailets;
> +
> +import org.apache.mailet.GenericMailet;
> +import org.apache.mailet.Mail;
> +import org.apache.mailet.RFC2822Headers;
> +
> +import javax.mail.MessagingException;
> +import javax.mail.internet.MimeBodyPart;
> +import javax.mail.internet.MimeMessage;
> +import javax.mail.internet.MimeMultipart;
> +import javax.mail.internet.MimePart;
> +
> +import java.io.IOException;
> +import java.io.UnsupportedEncodingException;
> +
> +/**
> + * An abstract implementation of a mailet that add a Footer to an email
> + */
> +public abstract class AbstractAddFooter extends GenericMailet {
> +
> +/**
> + * Takes the message and attaches a footer message to it. Right now, it
> only
> + * supports simple messages. Needs to have additions to make it support
> + * messages with alternate content types or with attachments.
> + *
> + * @param mail the mail being processed
> + *
> + * @throws MessagingException if an error arises during message
> processing
> + */
> +public void service(Mail mail) throws MessagingException {
> +try {
> +MimeMessage message = mail.getMessage();
> +
> +if (attachFooter(message)) {
> +message.saveChanges();
> +} else {
> +log("Unable to add footer to mail " + mail.getName());
> +}
> +} catch (UnsupportedEncodingException e) {
> +log("UnsupportedEncoding Unable to add footer to mail "
> ++ mail.getName());
> +} catch (IOException ioe) {
> +throw new MessagingException("Could not read message", ioe);
> +}
> +}
> +
> +/**
> + * Prepends the content of the MimePart as text to the existing footer
> + *
> + * @param part the MimePart to attach
> + *
> + * @throws MessagingException
> + * @throws IOException
> + */
> +protected void addToText(MimePart part) throws MessagingException,
> +IOException {
> +//log("Trying to add footer to " +
> part.getContent().toString());
> +String contentType = part.getContentType();
> +String content = (String) part.getContent();
> +
> +if (!content.endsWith("\n")) {
> +content += "\r\n";
>
[jira] Resolved: (JAMES-529) Add a GenericAddFooter for use in AddFooter and CommandListservFooter
[ http://issues.apache.org/jira/browse/JAMES-529?page=all ] Norman Maurer resolved JAMES-529: - Fix Version: 2.4.0 Resolution: Fixed > Add a GenericAddFooter for use in AddFooter and CommandListservFooter > - > > Key: JAMES-529 > URL: http://issues.apache.org/jira/browse/JAMES-529 > Project: James > Type: Task > Reporter: Norman Maurer > Assignee: Norman Maurer > Fix For: 2.4.0 > > We should build a GenericAddFooter class which should be used in AddFooter > and CommandListservFooter. So we can remove duplicate code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r413624 - in /james/server/trunk/src/java/org/apache/james/transport/mailets: AbstractAddFooter.java AddFooter.java CommandListservFooter.java
Author: norman
Date: Mon Jun 12 03:19:59 2006
New Revision: 413624
URL: http://svn.apache.org/viewvc?rev=413624&view=rev
Log:
Add an abstract class for adding a Footer. Change AddFooter and
CommandListservFooter to extend this class
Added:
james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java
Modified:
james/server/trunk/src/java/org/apache/james/transport/mailets/AddFooter.java
james/server/trunk/src/java/org/apache/james/transport/mailets/CommandListservFooter.java
Added:
james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java?rev=413624&view=auto
==
---
james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java
(added)
+++
james/server/trunk/src/java/org/apache/james/transport/mailets/AbstractAddFooter.java
Mon Jun 12 03:19:59 2006
@@ -0,0 +1,189 @@
+/***
+ * Copyright (c) 2006 The Apache Software Foundation. *
+ * All rights reserved.*
+ * --- *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you *
+ * may not use this file except in compliance with the License. You*
+ * may obtain a copy of the License at:*
+ * *
+ * http://www.apache.org/licenses/LICENSE-2.0 *
+ * *
+ * Unless required by applicable law or agreed to in writing, software *
+ * distributed under the License is distributed on an "AS IS" BASIS, *
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or *
+ * implied. See the License for the specific language governing *
+ * permissions and limitations under the License. *
+ ***/
+
+package org.apache.james.transport.mailets;
+
+import org.apache.mailet.GenericMailet;
+import org.apache.mailet.Mail;
+import org.apache.mailet.RFC2822Headers;
+
+import javax.mail.MessagingException;
+import javax.mail.internet.MimeBodyPart;
+import javax.mail.internet.MimeMessage;
+import javax.mail.internet.MimeMultipart;
+import javax.mail.internet.MimePart;
+
+import java.io.IOException;
+import java.io.UnsupportedEncodingException;
+
+/**
+ * An abstract implementation of a mailet that add a Footer to an email
+ */
+public abstract class AbstractAddFooter extends GenericMailet {
+
+/**
+ * Takes the message and attaches a footer message to it. Right now, it
only
+ * supports simple messages. Needs to have additions to make it support
+ * messages with alternate content types or with attachments.
+ *
+ * @param mail the mail being processed
+ *
+ * @throws MessagingException if an error arises during message processing
+ */
+public void service(Mail mail) throws MessagingException {
+try {
+MimeMessage message = mail.getMessage();
+
+if (attachFooter(message)) {
+message.saveChanges();
+} else {
+log("Unable to add footer to mail " + mail.getName());
+}
+} catch (UnsupportedEncodingException e) {
+log("UnsupportedEncoding Unable to add footer to mail "
++ mail.getName());
+} catch (IOException ioe) {
+throw new MessagingException("Could not read message", ioe);
+}
+}
+
+/**
+ * Prepends the content of the MimePart as text to the existing footer
+ *
+ * @param part the MimePart to attach
+ *
+ * @throws MessagingException
+ * @throws IOException
+ */
+protected void addToText(MimePart part) throws MessagingException,
+IOException {
+//log("Trying to add footer to " +
part.getContent().toString());
+String contentType = part.getContentType();
+String content = (String) part.getContent();
+
+if (!content.endsWith("\n")) {
+content += "\r\n";
+}
+content += getFooterText();
+
+part.setContent(content, contentType);
+part.setHeader(RFC2822Headers.CONTENT_TYPE, contentType);
+//log("After adding footer: " + part.getContent().toString());
+}
+
+/**
+ * Prepends the content of the MimePart as HTML to the existing footer
+ *
+ * @param part the MimePart to attach
+ *
+ * @throws MessagingException
+ * @throws IOException
+ */
+protected void addToHTML(MimePart part) throws MessagingException,
+IO
[jira] Assigned: (JAMES-529) Add a GenericAddFooter for use in AddFooter and CommandListservFooter
[ http://issues.apache.org/jira/browse/JAMES-529?page=all ] Norman Maurer reassigned JAMES-529: --- Assign To: Norman Maurer > Add a GenericAddFooter for use in AddFooter and CommandListservFooter > - > > Key: JAMES-529 > URL: http://issues.apache.org/jira/browse/JAMES-529 > Project: James > Type: Task > Reporter: Norman Maurer > Assignee: Norman Maurer > > We should build a GenericAddFooter class which should be used in AddFooter > and CommandListservFooter. So we can remove duplicate code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-529) Add a GenericAddFooter for use in AddFooter and CommandListservFooter
Add a GenericAddFooter for use in AddFooter and CommandListservFooter - Key: JAMES-529 URL: http://issues.apache.org/jira/browse/JAMES-529 Project: James Type: Task Reporter: Norman Maurer We should build a GenericAddFooter class which should be used in AddFooter and CommandListservFooter. So we can remove duplicate code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-340) Fill in missing Message-ID headers on outgoing mail
[ http://issues.apache.org/jira/browse/JAMES-340?page=comments#action_12415824 ] Norman Maurer commented on JAMES-340: - IS it really true that outlook not do this ? I don't use windows here so i don't know. Anyone can confirm ? > Fill in missing Message-ID headers on outgoing mail > --- > > Key: JAMES-340 > URL: http://issues.apache.org/jira/browse/JAMES-340 > Project: James > Type: New Feature > Components: SpoolManager & Processors > Versions: 3.0 > Environment: FreeBSD 5.2 > Reporter: Stephen Haberman > Attachments: SaveChanges.java, SenderIsLocalWithNoMessageID.java, > messageid.patch > > Starting in Outlook 2003, MS decided not to have it generate a Message-ID on > the client because people complained it put machine-specific details in the > email headers. So MS decided that it is now the responsibility of the user's > POP3/SMTP server to add the missing Message-ID for Outlook. > To have James do this, I created a SenderIsLocalWithNoMessageID matcher and a > SaveChanges mailet and put it in james-config.xml after the spam processors > to have JavaMail will fill in the Message-ID for us. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
