svn commit: r413586 - /james/server/trunk/phoenix-bin/bin/phoenix.sh
Author: norman Date: Sun Jun 11 23:03:23 2006 New Revision: 413586 URL: http://svn.apache.org/viewvc?rev=413586view=rev Log: Change to directory $PHOENIX_HOME/bin before start james to get sure the derbydb directory is created on the right place. Thx to Joachim Draeger for reporting this. See JAMES-527 Modified: james/server/trunk/phoenix-bin/bin/phoenix.sh Modified: james/server/trunk/phoenix-bin/bin/phoenix.sh URL: http://svn.apache.org/viewvc/james/server/trunk/phoenix-bin/bin/phoenix.sh?rev=413586r1=413585r2=413586view=diff == --- james/server/trunk/phoenix-bin/bin/phoenix.sh (original) +++ james/server/trunk/phoenix-bin/bin/phoenix.sh Sun Jun 11 23:03:23 2006 @@ -133,6 +133,9 @@ JVM_OPTS=$JVM_OPTS -Djava.security.manager fi +# change to the bin directory +cd $PHOENIX_HOME/bin + # Get the run cmd RUN_CMD=$JAVA_HOME/bin/java $JVM_OPTS \ $JVM_OPTS \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r413590 - /james/server/branches/v2.3/phoenix-bin/bin/phoenix.sh
Author: norman Date: Sun Jun 11 23:47:56 2006 New Revision: 413590 URL: http://svn.apache.org/viewvc?rev=413590view=rev Log: Change to directory $PHOENIX_HOME/bin before start james to get sure the derbydb directory is created on the right place. Thx to Joachim Draeger for reporting this. See JAMES-527 Modified: james/server/branches/v2.3/phoenix-bin/bin/phoenix.sh Modified: james/server/branches/v2.3/phoenix-bin/bin/phoenix.sh URL: http://svn.apache.org/viewvc/james/server/branches/v2.3/phoenix-bin/bin/phoenix.sh?rev=413590r1=413589r2=413590view=diff == --- james/server/branches/v2.3/phoenix-bin/bin/phoenix.sh (original) +++ james/server/branches/v2.3/phoenix-bin/bin/phoenix.sh Sun Jun 11 23:47:56 2006 @@ -133,6 +133,9 @@ JVM_OPTS=$JVM_OPTS -Djava.security.manager fi +# change to the bin directory +cd $PHOENIX_HOME/bin + # Get the run cmd RUN_CMD=$JAVA_HOME/bin/java $JVM_OPTS \ $JVM_OPTS \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-527) data-source for default derby maildb is configured with a relative path
[ http://issues.apache.org/jira/browse/JAMES-527?page=all ] Norman Maurer resolved JAMES-527: - Fix Version: 2.4.0 Resolution: Fixed Now we change to $PHOENIX_HOME/bin before start james. This seems to me a better solution then use getProperties() at the moment. Anyway we should maybe change the config for not using a relative path on derby configuration. data-source for default derby maildb is configured with a relative path --- Key: JAMES-527 URL: http://issues.apache.org/jira/browse/JAMES-527 Project: James Type: Bug Components: James Core Versions: 2.3.0, 2.4.0, 2.3.0b1 Environment: tested on windows, jre 1.5 Reporter: Joachim Draeger Assignee: Norman Maurer Priority: Minor Fix For: 2.3.0, 2.4.0 Data source is configured with a relative path in config.xml: dburljdbc:derby:../apps/james/var/derbydb;create=true/dburl The path is relative to the current directory when starting james. Calling run from the bin folder is allright. Calling it from James root directory bin\run.bat causes the db to be created in the uplevel directory. Possible solutions: - add a cd PHOENIX_HOME in start scripts - evaluate the PHOENIX_HOME enviroment variable in James -- 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-528) Add whitelist support
[ http://issues.apache.org/jira/browse/JAMES-528?page=comments#action_12415823 ] Vincenzo Gianferrari Pini commented on JAMES-528: - The difference between the existing matchers like SenderIsLocal or SenderIsRegex and the new IsInWhiteList matcher consists in the fact that the latter is not static (list hardcoded in config.xml) but dynamic (list stored in a database), personal (per local sender) and optionally grows automatically. The mailet that manages the list in the database is WhiteListManager. The following (that can be found both in javadoc and in config.xml) should explain more: !-- Whitelist Management -- !-- Manages for each local user a white list of remote addresses whose messages -- !-- should never be blocked as spam. -- !-- -- !-- If automaticInsert is true, it will check, for a local sender, if a remote recipient -- !-- is already in the list: if not, it will be automatically inserted. -- !-- This is under the interpretation that if a local sender X sends a message to a -- !-- remote recipient Y, then later on if a message is sent by Y to X it should be -- !-- considered always valid and never blocked; hence Y should be in the white list -- !-- of X. -- !-- -- !-- Another mode of operations is when a local sender sends a message to whitelistManagerAddress -- !-- with one of three specific values in the subject, to -- !-- (i) send back a message displaying a list of the addresses in his own list (displayFlag); -- !-- (ii) insert some new addresses in his own list (insertFlag); -- !-- (iii) remove some addresses from his own list (removeFlag). -- !-- In all of the three above cases the message will be ghosted and the postmaster will reply -- !-- to the sender. -- !-- -- !-- The sender name is always converted to its primary name (handling aliases). -- !-- mailet match=SMTPAuthSuccessful class=WhiteListManager onMailetException=ignore repositoryPathdb://maildb/repositoryPath automaticInserttrue/automaticInsert whitelistManagerAddress[EMAIL PROTECTED]/whitelistManagerAddress displayFlagdisplay/displayFlag insertFlaginsert/insertFlag removeFlagremove/removeFlag /mailet -- Add whitelist support - Key: JAMES-528 URL: http://issues.apache.org/jira/browse/JAMES-528 Project: James Type: New Feature Components: Matchers/Mailets (bundled) Versions: 2.3.0b1 Reporter: Vincenzo Gianferrari Pini Assignee: Vincenzo Gianferrari Pini Priority: Minor Fix For: 2.3.0b1 Add matcher/mailets providing whitelist support, to reduce false positives in anti-spam detection. -- 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]
[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] 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]
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=413624view=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=413624view=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,
+IOException {
+
[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]
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=413624view=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=413624view=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);
+
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=413653view=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=413653r1=413652r2=413653view=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=413653r1=413652r2=413653view=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]
[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]
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: processor name=my-remote-processor class=QAlias queue class=JMSQueue queuefactoryjms/myQF/queuefactory queuenamejms/myQ/queuename /spoolmanager /processor processor name=another-remote-processor class=QAlias queue class=JDBCQueue datasourcejdbc/myDS/datasource /queue /processor processor name=mq-remote-processor class=QAlias queue class=MQLink queuenamemQueue/queuename /spoolmanager /processor processor name=root queue jndi=queue/myRoot ... /queue mailet ... /processor 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: queue jndi=queue/myRoot/ 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: spoolmanager processor ... /processor /spoolmanager 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
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
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]
[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]
