cvs commit: jakarta-james/src/java/org/apache/james/transport/matchers SenderIs.java RecipientIs.java
pgoldstein2002/10/01 23:53:35
Modified:src/java/org/apache/james/transport/matchers SenderIs.java
RecipientIs.java
Log:
Making RecipientIs and SenderIs agree in behavior.
Revision ChangesPath
1.3 +5 -5
jakarta-james/src/java/org/apache/james/transport/matchers/SenderIs.java
Index: SenderIs.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/matchers/SenderIs.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- SenderIs.java 18 Jan 2002 02:48:38 - 1.2
+++ SenderIs.java 2 Oct 2002 06:53:35 - 1.3
@@ -9,10 +9,10 @@
import org.apache.mailet.GenericMatcher;
import org.apache.mailet.Mail;
+import org.apache.mailet.MailAddress;
import java.util.Collection;
import java.util.StringTokenizer;
-import java.util.Vector;
/**
* @version 1.0.0, 24/04/1999
@@ -22,11 +22,11 @@
private Collection senders;
-public void init() {
-StringTokenizer st = new StringTokenizer(getCondition(), , , false);
-senders = new Vector();
+public void init() throws javax.mail.MessagingException {
+StringTokenizer st = new StringTokenizer(getCondition(), , \t, false);
+senders = new java.util.HashSet();
while (st.hasMoreTokens()) {
-senders.add(st.nextToken());
+senders.add(new MailAddress(st.nextToken()));
}
}
1.3 +3 -4
jakarta-james/src/java/org/apache/james/transport/matchers/RecipientIs.java
Index: RecipientIs.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/matchers/RecipientIs.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- RecipientIs.java 18 Jan 2002 02:48:38 - 1.2
+++ RecipientIs.java 2 Oct 2002 06:53:35 - 1.3
@@ -10,8 +10,7 @@
import org.apache.mailet.GenericRecipientMatcher;
import org.apache.mailet.MailAddress;
-import java.util.HashSet;
-import java.util.Set;
+import java.util.Collection;
import java.util.StringTokenizer;
/**
@@ -21,11 +20,11 @@
*/
public class RecipientIs extends GenericRecipientMatcher {
-private Set recipients;
+private Collection recipients;
public void init() throws javax.mail.MessagingException {
StringTokenizer st = new StringTokenizer(getCondition(), , \t, false);
-recipients = new HashSet();
+recipients = new java.util.HashSet();
while (st.hasMoreTokens()) {
recipients.add(new MailAddress(st.nextToken()));
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-james/src/java/org/apache/james/smtpserver SMTPHandler.java
pgoldstein2002/10/01 23:57:56
Modified:src/java/org/apache/james/smtpserver SMTPHandler.java
Log:
Fix for parity bug in SMTP MAIL SIZE handling.
Added host, ip to all connection debug messages
Revision ChangesPath
1.30 +20 -10
jakarta-james/src/java/org/apache/james/smtpserver/SMTPHandler.java
Index: SMTPHandler.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/smtpserver/SMTPHandler.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- SMTPHandler.java 2 Oct 2002 06:12:03 - 1.29
+++ SMTPHandler.java 2 Oct 2002 06:57:56 - 1.30
@@ -349,7 +349,9 @@
new StringBuffer(64)
.append(Socket to )
.append(remoteHost)
-.append( closed remotely.);
+.append( ()
+.append(remoteIP)
+.append() closed remotely.);
getLogger().debug(errorBuffer.toString(), se );
}
} catch ( InterruptedIOException iioe ) {
@@ -358,7 +360,9 @@
new StringBuffer(64)
.append(Socket to )
.append(remoteHost)
-.append( timeout.);
+.append( ()
+.append(remoteIP)
+.append() timeout.);
getLogger().debug( errorBuffer.toString(), iioe );
}
} catch ( IOException ioe ) {
@@ -367,7 +371,9 @@
new StringBuffer(256)
.append(Exception handling socket to )
.append(remoteHost)
-.append(:)
+.append( ()
+.append(remoteIP)
+.append() : )
.append(ioe.getMessage());
getLogger().debug( errorBuffer.toString(), ioe );
}
@@ -398,7 +404,7 @@
* TODO: Remove this interface from the class and change the mechanism
*/
public void targetTriggered(final String triggerName) {
-getLogger().error(Connection timeout on socket);
+getLogger().error(Connection timeout on socket with + remoteHost + (
+ remoteIP + ));
try {
out.println(Connection timeout. Closing connection);
socket.close();
@@ -916,7 +922,7 @@
String responseString = 501 Syntactically incorrect value for SIZE
parameter;
writeLoggedFlushedResponse(responseString);
getLogger().error(Rejected syntactically incorrect value for SIZE
parameter.);
-return true;
+return false;
}
if (getLogger().isDebugEnabled()) {
StringBuffer debugBuffer =
@@ -936,19 +942,21 @@
.append(state.get(SENDER).toString())
.append( from host )
.append(remoteHost)
-.append( of size )
+.append( ()
+.append(remoteIP)
+.append() of size )
.append(size)
.append( exceeding system maximum message size of )
.append(maxmessagesize)
.append(based on SIZE option.);
getLogger().error(errorBuffer.toString());
-return true;
+return false;
} else {
// put the message size in the message state so it can be used
// later to restrict messages for user quotas, etc.
state.put(MESG_SIZE, new Integer(size));
}
-return false;
+return true;
}
@@ -1279,7 +1287,9 @@
.append(state.get(SENDER).toString())
.append( from host )
.append(remoteHost)
-.append( exceeding system maximum message size of )
+.append( ()
+.append(remoteIP)
+.append() exceeding system maximum message size of )
.append(maxmessagesize);
getLogger().error(errorBuffer.toString());
} else {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-james/src/java/org/apache/james/transport/mailets Redirect.java RemoteDelivery.java ServerTime.java ToProcessor.java UseHeaderRecipients.java
pgoldstein2002/10/02 00:27:44
Modified:src/java/org/apache/james/transport/mailets Redirect.java
RemoteDelivery.java ServerTime.java
ToProcessor.java UseHeaderRecipients.java
Log:
Added a DEBUG value to some of the mailets, to control the logged strings for these
mailets.
Thanks to Noel Bergman for the fix.
Revision ChangesPath
1.16 +28 -15
jakarta-james/src/java/org/apache/james/transport/mailets/Redirect.java
Index: Redirect.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/mailets/Redirect.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- Redirect.java 27 Sep 2002 11:33:13 - 1.15
+++ Redirect.java 2 Oct 2002 07:27:44 - 1.16
@@ -195,6 +195,11 @@
*/
public class Redirect extends GenericMailet {
+/**
+ * Controls certain log messages
+ */
+private final boolean DEBUG = false;
+
// The values that indicate how to attach the original mail
// to the redirected mail.
@@ -419,23 +424,27 @@
*
*/
public void init() throws MessagingException {
-log(redirect init);
+if (DEBUG) {
+log(Redirect init);
+}
if(isStatic()) {
-sender = (getSender() == null) ?
getMailetContext().getPostmaster() : getSender();
-replyTo = (getReplyTo() == null) ?
getMailetContext().getPostmaster() : getReplyTo();
+sender = getSender();
+replyTo = getReplyTo();
messageText = getMessage();
recipients = getRecipients();
apparentlyTo = getTo();
-StringBuffer logBuffer =
-new StringBuffer(1024)
-.append(static, sender=)
-.append(sender)
-.append(, replyTo=)
-.append(replyTo)
-.append(, message=)
-.append(messageText)
-.append( );
-log(logBuffer.toString());
+if (DEBUG) {
+StringBuffer logBuffer =
+new StringBuffer(1024)
+.append(static, sender=)
+.append(sender)
+.append(, replyTo=)
+.append(replyTo)
+.append(, message=)
+.append(messageText)
+.append( );
+log(logBuffer.toString());
+}
}
}
@@ -458,7 +467,9 @@
MimeMessage reply = null;
//Create the message
if(getInLineType() != UNALTERED) {
-log(alter message inline=: + getInLineType());
+if (DEBUG) {
+log(Alter message inline=: + getInLineType());
+}
reply = new
MimeMessage(Session.getDefaultInstance(System.getProperties(),
null));
StringWriter sout = new StringWriter();
@@ -535,7 +546,9 @@
} else {
// if we need the original, create a copy of this message to redirect
reply = getPassThrough() ? new MimeMessage(message) : message;
-log(message resent unaltered:);
+if (DEBUG) {
+log(Message resent unaltered.);
+}
}
//Set additional headers
reply.setSubject(getSubjectPrefix() + message.getSubject());
1.29 +34 -21
jakarta-james/src/java/org/apache/james/transport/mailets/RemoteDelivery.java
Index: RemoteDelivery.java
===
RCS file:
/home/cvs/jakarta-james/src/java/org/apache/james/transport/mailets/RemoteDelivery.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- RemoteDelivery.java 30 Sep 2002 23:38:58 - 1.28
+++ RemoteDelivery.java 2 Oct 2002 07:27:44 - 1.29
@@ -57,6 +57,11 @@
*/
public class RemoteDelivery extends GenericMailet implements Runnable {
+/**
+ * Controls certain log messages
+ */
+private final boolean DEBUG = false;
+
private SpoolRepository outgoing; // The spool of outgoing mail
private long delayTime = 2160; // default is 6*60*60*1000 millis (6 hours)
private int maxRetries = 5; // default number of retries
@@ -146,7 +151,9 @@
*/
private boolean deliver(MailImpl mail, Session session) {
try {
-log(attempting to deliver +
RE: [PATCH] NNTP Server fixes
A comment like '// see section ...' is far more helpful to me than say javadoc style comments on a private variable. IMHO I'd agree that javadocs should only be used on public and package scope methods and fields. Private fields and methods need only be commented, and privately, where their use is not clear from the code. I subscribe to the XP view that a requirement for extensive commenting of sources is in avoidance of writing clear code. Obviously this has to be tempered, in a OS project particularly, with the need to make the code accessable to any would be developer, and frankly I think James own code is not the inscrutable part of this, the steep learning curve for interested participants is James use of Avalon in all its guises. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] NNTP Server fixes
Danny, I subscribe to the XP view that a requirement for extensive commenting of sources is in avoidance of writing clear code. I don't necessarily disagree with this view - on XP projects. As we discussed on the list the last time this came up, there are a number of XP methodologies that are precisely designed to spread the knowledge in lieu of code commenting (developer rotation, pair programming, design reviews, etc.). James developers don't have the benefit of any of these methodologies, so commenting is correspondingly more important as a tool for inter-developer communication. Obviously this has to be tempered, in a OS project particularly, with the need to make the code accessable to any would be developer, and frankly I think James own code is not the inscrutable part of this, the steep learning curve for interested participants is James use of Avalon in all its guises. Speaking as someone who recently came up to speed on the James and Avalon code, I'd have to disagree with this assertion. The Avalon code and lifecycle were very easy to pick up - precisely because Avalon is very well documented. I found the James code far more confusing and inscrutable. --Peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Mailet API logging and other changes
Noel, All, Lets leave the Mailet logging, and other mailet API issues 'till after the release. There are a number of potential changes we need to discuss to the API and James' implementation of it. I'm prepared to review my opposition to advanced logging in the API, but not right now. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Mailet API logging and other changes
Danny et al, Lets leave the Mailet logging, and other mailet API issues 'till after the release. +1 I concur. Focusing on the release now (and getting it out) will help us resolve these issues sooner. --Peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Log level for Mailet Exceptions
Danny Angus wrote: Currently we're stuck with this problem, so we have to pick a global compromise between verbosity and lose of critical information. Until this problem can be fixed, at the least exceptions thrown by a mailet should be considered a warning, if not an error. True, some of them aren't, but we're still stuck with a compromise, and better to assume that an exception is important than to discard it. As far as I'm concerned the logging of mailets should be an issue for mailet developers, developers are free to use commons logging or anything else in their mailets, as is the case in the servlet API. Danny: Have to jump in and disagree with you on this (partially :-) ). The issue of logging is firtly a management issue - not a developer issue. Logging information crossing boundaries of multiple application and frameworks, coordinated under a single management context is absolutely important. Take for example the execution of James, some mailest, an ORB, and throw in a few Servlets - if the logging management is not unified it becomes impossible to seperate operational management from the developer maindset. Today I can run all of the above using a single logging strategy and keep logging tools and targets seperate from the individual implementations. Will this be true for Mailets? Cheers, Steve. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Mailet Logging == Jakarta Commons (org.apache.commons.logging)
Danny Angus wrote: Almost no application's primary concern is logging. James has exactly the same concern with logging that other server applications, such as Apache and Tomcat, have: the need to record information about the application's operation. Providing an API is not the same as providing a mechanism. Adopting the Jakarta Commons Logging API would be one way to provide a standard contract without specifying the runtime mechanism. But log(String) and log(String, Exception) are insufficient. And yet Tomcat and the servlet API you quote provide only for log(String) leaving any more sophisticated logging requirement to the discretion of servlet writers. ... and massive headaches for developers attempting to unify things. Leaving this sort of thing to the discretion of the servlet writers is just plain bad. I've has spent way to much time wrapping and working around logging systems because of APIs that havn't considered that tools are deployed in an environment where the developer is out of the picture. Logging is more related to management policies that anything from a developer. Cheers, Steve. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Log level for Mailet Exceptions
... the logging of mailets should be an issue for mailet developers, developers are free to use commons logging or anything else in their mailets, as is the case in the servlet API. d. agreed to a point - one log for mailets and a defined interface (api) to use to log mailet activity. Although coders should be free to implement whatever they want, a firm and concise framewrok should be available. alan Alan Gerhard Gerhard Computing, Inc. [EMAIL PROTECTED] -- This EMail Was brought to you by WebMail A Netwin Web Based EMail Client http://netwinsite.com/webmail/tag.htm -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] NNTP Server fixes
- Original Message - From: Peter M. Goldstein [EMAIL PROTECTED] i) Current solution is broken, not only implementation-wise but also design/architecture That is why I am agreeing with you to replace it. ii) Correctly designing a pluggable, flexible, correct authentication/authorization mechanism is highly non-trivial. It It may not be the best mechanism, but AuthServiceFactory fixes the problem you found and it is better than coupling auth stuff inside handler. We do not have the time to do this properly without pushing out the release. I'll make sure AuthService issue is corrected before release. The change delta will be smaller with AuthServiceFactory from current codebase. We have so far talked about what should not be. Let us talk about what should be the right way. ideas... thanks, Harmeet -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Mailet Logging == Jakarta Commons (org.apache.commons.logging)
Further, my understanding is that this will not be addressed until James 2, which leaves ample time to establish this concept/principle. Actually, we're already doing James 2.1, so a major release that changes interfaces ought to be called James 3 (Mailet API v2). But a rose by any other name ... --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
A survey about handling bugs in open source projects
Hello all James contributors, I am conducting a survey about the way defects (or bugs-I use these two words interchangeably) are handled in open source software projects. It is very easy to fill out. It consists of three short sections which can be completed at once or in different sessions. The survey can be found in the address: http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html This survey includes questions that can be answered by developers,testers, bug fixers, bug database owners, and project managers. I would greatly appreciate if you could visit the above web page and fill out the survey. I am sure you will find the questions very interesting and thought provoking. We need the help of all contributors of James in the above roles to understand how we can use bugs data collected in your project for software engineering research. Nowadays, there is a huge amount of bug data on the Internet collected during the development of all open source products. A bug database include useful information to identify high-risk, problem-prone modules (components) in the software. It is also possible to measure these problem-prone components using several complexity metrics (McCabe's cyclomatic complexity, Halstead's metrics, etc.), since the source code is available. If a characterization, which is generalizable across many projects (sub-projects) could be made in terms of complexity, focused quality improvement would become possible in the future projects. So far, in the literature, there is quite amount of evidence that 80 percent of the problems occur from 20 percent of the modules (or software components), which gives hope toward tremendous quality increase, time savings, and increased success in the open source projects. Also a bug database includes useful information about the efficiency of development. For example, if a lot of bugs related to design of the system are found after release, when coding bugs are expected more, then this may indicate that the design or architecture of the system was done cursory. Of course, these kinds of conclusions would require some kind of classification of bugs according to their insertion time after they get fixed. However, before trying to find an answer to the questions like above, our first step is to understand if the available data is usable for empirical research purposes. This means having an idea about the consistency of bug reports and fixes, accuracy of data, completeness of the data, etc. At this point, we need your help. By filling out this survey, you will help us understand availability, representativeness, and characteristics of the data in the bug database of your project. I'd like to stress that the purpose of this survey is only and only research. Open source development gained a very good momentum in the last decade. We hope that outcomes of our research will help even increase this momentum. We will acknowledge the help of all supporting communities when mentioning our results. In addition to these goals, we also think that filling out this short survey can lead to some immediate brain-storming in individuals and groups, and exchange of ideas among the James community, which will be useful too. As I said, you will find the survey questions interesting. If you'd prefer to learn more about our research, I included a link in the above web page of our survey. This link provides more information about our research. Once more, your contribution is very important to us. Please visit http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html and fill out our survey. We greatly appreciate your helps. Please contact me for any question you might have. Thanks -- *** A. Gunes Koru Research Assistant, Ph.D. Student Southern Methodist University Computer Science and Engineering Department 6425 North Ownby Drive Science and Information Building Room 317 Dallas, TX 75205 Home: 214 691 5633 Work: 214 768 2005 Cell: 214 893 7311 http://www.seas.smu.edu/~gkoru Email: [EMAIL PROTECTED] *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Mailet API logging and other changes
Lets leave the Mailet logging, and other mailet API issues 'till after the release. I wasn't planning to make any changes, other than reduce some debugging output, until after the release. Certainly not API changes! I'm not looking to cause a problem. :-) As things stand, I'm done. Other than checking in some new mailet/matcher code, I've got nothing on my plate for 2.1 release. Which is good, since Peter wants feature freeze tomorrow. :-) The logs are very important to me. I maintain a monitor in the upper righthand side of my workstation watching all of the James logs in real-time. If anything, I have added some useful logging information, e.g., when a socket times out now, we now log with whom it timed out. OTOH, too much tracing information, once the code works, can mask real problems. One thing that I really want for the next release is the ability to dynamically configure logging. For example, if I suspect a problem in handshaking, I want to be able to turn on debug for a protocol handler, and then turn it off afterwards. Right how I have to reboot to affect that change. There are a number of potential changes we need to discuss to the API and James' implementation of it. The storage interface is the other major area that comes to mind. I'm prepared to review my opposition to advanced logging in the API, but not right now. I agree. API changes should all be post-2.1. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] NNTP Server fixes
That is why I am agreeing with you to replace it. OK, point of agreement. You both think that the authentication mechanism is fundamentally flawed at the architecture level, and should be replaced. :-) It may not be the best mechanism, but AuthServiceFactory fixes the problem you found and it is better than coupling auth stuff inside handler. I believe that Peter feels that what he's done is a quick hack to make it work, and since both of you agree that the whole thing should be ripped out, tossed, and replaced as soon as 2.1 is closed he'd rather go with something that he's been testing rather than start again right now with an AuthServiceFactory that he expects would ALSO be ripped, tossed and replaced. If I am reading both of you correctly, then his point of view makes some sense. Rather than invest the time in AuthServiceFactory now, with the intent of replacing it anyway, why not go out the door with his code (if it works), and then start the discussion about proper design? I'll make sure AuthService issue is corrected before release. The change delta will be smaller with AuthServiceFactory from current codebase. My personal view is that we're getting down to the short straws on the 2.1 release, and I'm getting very antsy about changes. You get a vote, I don't, but there have been several bugs introduced recently that came from innocent little fixes and code refactoring. Bugs happen. The only way to guarantee that you don't introduce a new one is not to change code. So unless we have a bug to fix, I'd just as soon not change code. Peter still has connection handling changes that he wants to check in, which makes me very nervous at this late date. We have so far talked about what should not be. Let us talk about what should be the right way. ideas... The sense that I get from Peter's messages is that he wants to focus on getting 2.1 out, and not lose his focus by getting into tangential discussion on future architecture. This is similar to why Danny wants to put off discussion about the Mailet API until later, and why I'd like him to put off discussing the store interface, too. Because we all want to be able to participate and discuss those, but right now we're trying to focus on the current codebase. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Commenting Issues
[Coalescing the NNTP server discussion on commenting] IMHO I'd agree that javadocs should only be used on public and package scope methods and fields. [Danny] I can agree that javadocs MUST be used on public/package scope items. I won't say that they MUST NOT be used elsewhere. I just don't have any particular cares about the latter. Private fields and methods need only be commented, and privately, where their use is not clear from the code. [Danny] Ok, this means that most of them should be commented except for the most trivial. However, I am of the mind that comments should be a way of telling another programmer (or myself, much later), what and why. Especially the why. A comment like: item.unlock(); // remove the lock is worthless. I can see that we are calling the unlock method. But a comment like: // spool.remove() has a side-effect! It unlocks the // message so that other threads can work on it! If // we don't remove it, we must unlock it! spool.unlock(key); tells me something important about the operation of the code. I subscribe to the XP view that a requirement for extensive commenting of sources is in avoidance of writing clear code. [Danny] [Personal aside: XP is nothing more than a marketing slick relabeling for Gen-Xers of tried and true practices, many of which date back 30 years or more.] IAE, what is clear to one programmer who knows an RFC inside-out may not be clear to another. I put that comment about spooling in for the next person who wanted to work on that code. By the time I figured out how spooling worked, the code would have been clear to me (at least for the duration of that week ;-)). Obviously this has to be tempered, in a OS project particularly, with the need to make the code accessable to any would be developer [Danny] I agree that we must establish the mindset that we at least have to comment the code as if we were explaining it to another person so that they can make changes. Which is, of course, what we're really doing. This is basically what you and Peter are both agreeing. As Peter said, James developers don't have the benefit of any of these [face-to-face XP] methodologies [that enhance communication between developers], so commenting is correspondingly more important as a tool for inter-developer communication. - Not do javadocs on private methods/variables. There does not really seem to be a gain in javadoc for implementation details. [Harmeet] All methods/variables should be documented. I don't understand how you can say there is no gain in javadocing implementation details. [Peter] Javadocs !== documentation. Javdocs = documentation. He isn't saying that methods/variables should not be documented. He's just saying that he doesn't see the gain of using javadoc tags for private implementation items. In fact, I could argue that exposing that private members with javadoc tags is dangerous, on the grounds that implementation details should not be exposed outside of the source. We don't want someone to read the javadocs and make assumptions about implementation. Only those things that make up the contract should be javadoc'd. I'm willing to listen to a contrary view, but please explain it. The primary goal of documentation is to convey an understanding of the code to developers other than the author. [Peter] Peter, the good news is that no one appears to be disagreeing about commenting. The issue here appears to be only whether or not to use javadoc tags within the comments for private items. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] NNTP Server fixes
Harmeet, You're again missing the point. ii) Correctly designing a pluggable, flexible, correct authentication/authorization mechanism is highly non-trivial. It It may not be the best mechanism, but AuthServiceFactory fixes the problem you found and it is better than coupling auth stuff inside handler. We do not have the time to do this properly without pushing out the release. I'll make sure AuthService issue is corrected before release. The change delta will be smaller with AuthServiceFactory from current codebase. No, a simple AuthServiceFactory hack is not better than the current situation. A simple AuthServiceFactory would further expose the lousy AuthService interface - which remains wrong for all the reasons I discussed earlier. There never was a pluggable AuthService. And AuthService had other, substantial issues that I corrected by incorporating it into the handler (Exposure of user/password as sole authentication mechanism, failure to wipe username/password on bad auth, etc.). I'm not interested in minimizing the delta from the past code base. I'm interested in minimizing the delta from the current, correct, tested code base. And no change like the one you're proposing is going to do that. We have so far talked about what should not be. Let us talk about what should be the right way. ideas... And that's exactly what we shouldn't be doing so close to a release. Planning new architectural changes for things that haven't worked for nine months, after they've just been fixed, is ridiculous. But since you asked, here goes: I want an AuthService that allows me to load different JAAS providers for the purpose of authentication, to allow us to take advantage of numerous third-party authentication modules. It should have per-protocol callbacks, to allow us to use the same root class for all of the James services authentication needs. A limitation to user/password is obviously not acceptable. It should support complex, dynamic policy definition and should be able to link into external policy engines for authorization (i.e. RSA ClearTrust, IBM Policy Director) as well as into a simple home-grown policy class. Of course everyone agrees with me on this one, right? We're going to have this by tomorrow, right? Of course not. As I've tried to explain, doing something like this properly is difficult. It's not something you toss on the end of a release. There are a number of issues that need to be discussed and clarified. And it affects basically the whole server. --Peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] NNTP Server fixes
I want an AuthService that allows me to load different JAAS providers for the purpose of authentication ... Sounds like a good Avalon Service, too. Any service within Avalon that had an authentication notion could use it. So perhaps we can get the Avalon guys into the discussion, although for first release I'd rather have it under James control (CVS, scheduling, etc.) than Avalon. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] NNTP Server fixes
AuthService etc. discussion is moot. It has already been checked in, inspite of a offer of discussion and -1 on that change. Seems like a waste of time for now to discuss this anymore. Harmeet - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] Sent: Oct 2, 1:13 PM That is why I am agreeing with you to replace it. OK, point of agreement. You both think that the authentication mechanism is fundamentally flawed at the architecture level, and should be replaced. :-) It may not be the best mechanism, but AuthServiceFactory fixes the problem you found and it is better than coupling auth stuff inside handler. I believe that Peter feels that what he's done is a quick hack to make it work, and since both of you agree that the whole thing should be ripped out, tossed, and replaced as soon as 2.1 is closed he'd rather go with something that he's been testing rather than start again right now with an AuthServiceFactory that he expects would ALSO be ripped, tossed and replaced. If I am reading both of you correctly, then his point of view makes some sense. Rather than invest the time in AuthServiceFactory now, with the intent of replacing it anyway, why not go out the door with his code (if it works), and then start the discussion about proper design? I'll make sure AuthService issue is corrected before release. The change delta will be smaller with AuthServiceFactory from current codebase. My personal view is that we're getting down to the short straws on the 2.1 release, and I'm getting very antsy about changes. You get a vote, I don't, but there have been several bugs introduced recently that came from innocent little fixes and code refactoring. Bugs happen. The only way to guarantee that you don't introduce a new one is not to change code. So unless we have a bug to fix, I'd just as soon not change code. Peter still has connection handling changes that he wants to check in, which makes me very nervous at this late date. We have so far talked about what should not be. Let us talk about what should be the right way. ideas... The sense that I get from Peter's messages is that he wants to focus on getting 2.1 out, and not lose his focus by getting into tangential discussion on future architecture. This is similar to why Danny wants to put off discussion about the Mailet API until later, and why I'd like him to put off discussing the store interface, too. Because we all want to be able to participate and discuss those, but right now we're trying to focus on the current codebase. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] NNTP Server fixes
Actually, I think that discussion of an authentication service will be a vital discussion. The current code is not expected to live any longer than it takes to have that discussion, and replace it. But although I am not convinced that Peter's solution isn't the right one for the extreme short term, I don't recall seeing a -1 vote. Where did I miss it? For that matter, I don't recall seeing anyone vote on the release plan. But the idea appears to be that James 2.1 gets frozen within the next week or so, released in a month, and then your new AuthService starts getting significant effort. So no one is abandoning the idea. --- Noel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 15:02 To: James Developers List Subject: RE: [PATCH] NNTP Server fixes AuthService etc. discussion is moot. It has already been checked in, inspite of a offer of discussion and -1 on that change. Seems like a waste of time for now to discuss this anymore. Harmeet - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] Sent: Oct 2, 1:13 PM That is why I am agreeing with you to replace it. OK, point of agreement. You both think that the authentication mechanism is fundamentally flawed at the architecture level, and should be replaced. :-) It may not be the best mechanism, but AuthServiceFactory fixes the problem you found and it is better than coupling auth stuff inside handler. I believe that Peter feels that what he's done is a quick hack to make it work, and since both of you agree that the whole thing should be ripped out, tossed, and replaced as soon as 2.1 is closed he'd rather go with something that he's been testing rather than start again right now with an AuthServiceFactory that he expects would ALSO be ripped, tossed and replaced. If I am reading both of you correctly, then his point of view makes some sense. Rather than invest the time in AuthServiceFactory now, with the intent of replacing it anyway, why not go out the door with his code (if it works), and then start the discussion about proper design? I'll make sure AuthService issue is corrected before release. The change delta will be smaller with AuthServiceFactory from current codebase. My personal view is that we're getting down to the short straws on the 2.1 release, and I'm getting very antsy about changes. You get a vote, I don't, but there have been several bugs introduced recently that came from innocent little fixes and code refactoring. Bugs happen. The only way to guarantee that you don't introduce a new one is not to change code. So unless we have a bug to fix, I'd just as soon not change code. Peter still has connection handling changes that he wants to check in, which makes me very nervous at this late date. We have so far talked about what should not be. Let us talk about what should be the right way. ideas... The sense that I get from Peter's messages is that he wants to focus on getting 2.1 out, and not lose his focus by getting into tangential discussion on future architecture. This is similar to why Danny wants to put off discussion about the Mailet API until later, and why I'd like him to put off discussing the store interface, too. Because we all want to be able to participate and discuss those, but right now we're trying to focus on the current codebase. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] make DEBUG configurable
This is just a quick patch so that instead of
private final boolean DEBUG = false;
we have:
private boolean DEBUG = false;
and then
public void init() ... {
DEBUG = (getInitParameter(debug) == null) ? false : new
Boolean(getInitParameter(debug)).booleanValue();
...
}
So any mailet that would emit additional log information when debugging can
be controlled by:
mailet ...
debugtrue | false/debug
/mailet
This allows developers and admins to get additional debugging information
without having to recompile.
Please sanity check. We don't want mistakes even in something this
seemingly simple. :-)
--- Noel
james-diffs
Description: Binary data
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] HasHeader matcher
This is a complement to the AddHeader mailet. Usage: mailet match=header name ... / Will be further enhanced in the future, after the feature freeze window re-opens. --- Noel HasHeader.java Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] JDBCVirtualUserTable
This is the mailet we've been using since mid-August to handle virtual domains and users. Full documentation is in the header comment: /** * Implements a Virtual User Table for JAMES. Derived from the * JDBCAlias mailet, but whereas that mailet uses a simple map from a * source address to a destination address, this handles simple * wildcard selection, verifies that a catchall address is for a domain * in the Virtual User Table, and handles forwarding. * * With JDBCAlias, if the destination address were remote it would be * subject to relay testing, even though it should be treated as a local * address. JDBCVirtualUserTable incorporates JDBCAlias processing for * local destinations, and Forward processing for remote destinations. * * To prevent from breaking existing JDBCAlias applications, and to * allow for evolution of this mailet, it is released as a new mailet, * rather than as an update to JDBCAlias. However, anyone using * JDBCAlias should be able to upgrade to JDBCVirtualUserTable. * * As with JDBCAlias, JDBCVirtualUserTable does not provide any * administation tools. You'll have to create the VirtualUserTable * yourself. The standard configuration is as follows: * * CREATE TABLE VirtualUserTable * ( * user varchar(64) NOT NULL default '', * domain varchar(255) NOT NULL default '', * target_address varchar(255) NOT NULL default '', * PRIMARY KEY (user,domain) * ); * * The standard query used with VirtualUserTable is: * * select VirtualUserTable.target_address from VirtualUserTable, VirtualUserTable as VUTDomains * where (VirtualUserTable.user like ? or VirtualUserTable.user like \%) * and (VirtualUserTable.domain like ? * or (VirtualUserTable.domain like \% and VUTDomains.domain like ?)) * order by concat(VirtualUserTable.user,'@',VirtualUserTable.domain) desc limit 1 * * For a given [user, domain, domain] used with the query, this will * match as follows (in precedence order): * * 1. user@domain- explicit mapping for user@domain * 2. user@% - catchall mapping for user anywhere * 3. %@domain - catchall mapping for anyone at domain * 4. null - no valid mapping * * You need to set the connection. At the moment, there is a limit to * what you can change regarding the SQL Query, because there isn't a * means to specify where in the query to replace parameters. [TODO] * * lt;mailet match=All class=JDBCVirtualUserTablegt; * lt;tablegt;db://maildb/VirtualUserTablelt;/tablegt; * lt;sqlquerygt;sqlquerylt;/sqlquerygt; * lt;/mailetgt; * * @author Noel J. Begman [EMAIL PROTECTED] */ JDBCVirtualUserTable.java Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-james/src/conf james-server.xml
pgoldstein2002/10/02 17:33:51
Modified:src/conf james-server.xml
Log:
Fixing a minor bug in the default logging configuration that makes it difficult for
an
administrator to determine whether a log entry occurred ante meridian or post
meridian. With
this change log entries are printed with a 24 hour format.
Revision ChangesPath
1.10 +17 -17jakarta-james/src/conf/james-server.xml
Index: james-server.xml
===
RCS file: /home/cvs/jakarta-james/src/conf/james-server.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- james-server.xml 30 Sep 2002 17:21:14 - 1.9
+++ james-server.xml 3 Oct 2002 00:33:50 - 1.10
@@ -95,87 +95,87 @@
targets
file id=default
filename${app.home}/logs/default.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file id=James-Mailet-target
filename${app.home}/logs/mailet.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file id=James-target
filename${app.home}/logs/james.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file id=spoolmanager-target
filename${app.home}/logs/spoolmanager.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file id=dnsserver-target
filename${app.home}/logs/dnsserver.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file id=remotemanager-target
filename${app.home}/logs/remotemanager.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file id=pop3server-target
filename${app.home}/logs/pop3server.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file id=smtpserver-target
filename${app.home}/logs/smtpserver.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file id=nntpserver-target
filename${app.home}/logs/nntpserver.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file id=nntp-repository-target
filename${app.home}/logs/nntpstore.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file id=mailstore-target
filename${app.home}/logs/mailstore.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file id=users-store-target
filename${app.home}/logs/usersstore.log/filename
-format%{time:dd/MM/yy hh:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
+format%{time:dd/MM/yy HH:mm:ss} %5.5{priority} %{category}:
%{message}\n%{throwable}/format
appendtrue/append
/file
file
