RE: Possible Synchronization Issue

Harmeet, While I don't necessarily disagree with the notion behind the suggested approach, I can't find the precedents you reference. I'm especially confused because, as I understood it, the declaration of a number of methods in SimpleDateFormat and DateFormat as either final or private makes t

RE: Further Development...

opers List Subject: Re: Further Development... On Friday 26 July 2002 03:23 pm, Peter M. Goldstein wrote: > 6) Tight interaction with the Avalon team to ensure that future > revisions of Avalon/Phoenix meet James' needs There are now a few Avalon/Phoenix committers hanging out to make sur

FW: Question about SMTP AUTH and mozilla and apple mail

Noel, There was already a thread on james-dev as a result of the bugzilla modification (see emails of 7/2/02), but point taken. Attached is the diff. This patch is designed to resolve bug #6340 in the least intrusive way - by keeping the scope of the AUTH PLAIN specific argument parsing to wit

[PATCH] Bug #6340

All, Sorry. Previous message did not have an appropriate subject line. --Peter -Original Message- From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] Sent: Friday, July 26, 2002 6:45 PM To: 'James Developers List' Subject: FW: Question about SMTP AUTH and mozilla and

RE: [PATCH] Bug #6340

illa it would explain > why it had been ignored. > > > -Original Message- > > From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] > > Sent: 27 July 2002 02:47 > > To: 'James Developers List' > > Subject: [PATCH] Bug #6340 > > > > > >

RE: Avalon feedback request

Stephen and Danny, One issue is discussed in bug #9628. That bug fundamentally came down to case sensitivity for Booleans in the Avalon AbstractConfiguration class. From what I've read on the Avalon-dev mailing list, I believe that issue has been resolved in Avalon. --Peter -Original Mes

[PATCH] Bug #11233

All, The attached files constitute a patch to James to restore thread safety to its date formatting, addressing the issues discussed in bug #11233. This is the second revision of these changes, spurred mostly by Harmeet's response to the first, simpler revision. Please see my email of 7/2/2002

[PATCH] Bug #11234

All, This is a patch to the POP3Handler.java class that resolves Bug #11234. Rather than the password being logged to the log file, a special string "" is logged instead. --Peter POP3Handler.java.diff Description: Binary data -- To unsubscribe, e-mail: For addi

RE: [PATCH] Diff for James.java to use (or use not) IMAP

Sascha, A couple of quick comments. 1) Any change of this nature will require that the org.apache.james.imapserver.* Java files currently in the proposal directory be shifted to the main directory. What is the status of those files? If we don't do this, then the build will break

RE: Avalon feedback request

Stephen, > Personally I would like to see > (a) improvements in the framework usage Any specific, immediate recommendations? > (b) cleaning up of Avalon Excalibur dependencies (the Excalibur >packages has > been cleaned up a lot and you can now limit your dependencies to >only >

[PATCH] Bug #6812

All, The attached files are a patch for bug #6812, improper handling of absolute file URLs. Basically they consist of a check to see whether the URL starts with '/' after the initial file:// protocol prefix. If so, the initial '/' is stripped off and the resulting string is taken as the file

[PATCH] Bug #6812 (take 2)

All, Sorry. I inadvertently introduced a bug in the absolute URL handling in the previous revision of this fix by stripping off the leading '/'. That'll cause a problem on non-Windows systems. Here's a corrected fix. --Peter -Original Message- From: Peter M. Gold

[PATCH] Bug in submission

All, Somehow the '!' operator got left out of the if clause in my earlier submitted diffs. For that patch to correct the attached diffs need to be applied. My apologies for the confusion. --Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, Jul

RE: [Bug 11235] Extensive use of string concatenation throughout code base

Noel, I've actually had all of this done for a few weeks now. My biggest question has been how to post it in a way that it doesn't overload the capacity of the list to vet the changes. It's a pretty wide-spread set of changes. I guess I could start by submitting a couple of the more substanti

RE: [Bug 11235] Extensive use of string concatenation throughout code base

Andrei, That would be great to see a standardized set of closes for the custom streams (as well as a specified order of closure). I'm going to have to disagree with both you and Noel on the severity and performance impact of string concatenation. HotSpot or not, the performance penalty for tha

RE: [Bug 11235] Extensive use of string concatenation throughout code base

turing the whole output) 3/ You'd better make sure it really all works first time. d. > -Original Message- > From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] > Sent: 28 July 2002 21:16 > To: 'James Developers List' > Subject: RE: [Bug 11235] Extensive use

RE: [Bug 11243] New: - SMTP server against DB repository doesn't scale with message size

All, Personally I find this a really troubling bug. Seems like database repository behavior should be more, not less, scalable than file repository behavior. I'd like to collect info from anyone who's seen it. I've noticed at least a couple of places in the code base that may be contributing

RE: DO NOT REPLY [Bug 9669] - Embedded whitespace in To address field crashed James

Danny, The essential problem is that an incoming header isn't necessarily legal by RFC 822 (or followup RFC standards). What's happening here is that there is an illegal To header on the incoming message. The To header has the specific form "". According to the assorted mail RFCs, anything in

RE: DO NOT REPLY [Bug 9669] - Embedded whitespace in To address field crashed James

> Subject: Re: DO NOT REPLY [Bug 9669] - Embedded whitespace in To address > field crashed James > > Does this mean that anybody can crash the mail server by sending a > malformed > email? > > - Original Message - > From: "Peter M. Goldstein" <[EMAI

RE: Inactivity

Labib, I did review your suggested patches although I didn't post a reply to the lists. The raise header code looks mostly ok, with a couple of caveats. i) I don't think there should be a hardcoded 2 sec delay for the bounce window. ii) I don't understand why the raiseHeader method is returni

RE: Inactivity

Labib, > ii) I don't understand why the raiseHeader method is returning "1" when > it is passed a null. To me this looks like an exceptional condition. I > would expect the method to throw an exception to indicate that something > unexpected happened. Ignore this caveat. Looking at the method

RE: cvs commit: jakarta-james/lib mm.mysql.LICENCE mm.mysql-2.0.14.jar mysql-2.0.4.jar

Danny, Shouldn't that be mm.mysql.LICENSE ? --Peter > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 29, 2002 6:40 AM > To: [EMAIL PROTECTED] > Subject: cvs commit: jakarta-james/lib mm.mysql.LICENCE mm.mysql- > 2.0.14.jar mysql-2.0.4.jar >

RE: Inactivity

Labib, > it is not that I am too keen on my code being included, but I am still > glad > to get some response. > Maybe I didn't make clear what the intent of my patches was: > I didn't want to add any feature. I just wanted to change JAMES a little > bit > to behave friendlier even in unexpected

RE: DO NOT REPLY [Bug 11256] New: - SMTP server unexpectedly kills connection when received bad parameter for SMTP AUTH

All, This bug was reported on the james-user list. From the bug description: > The behavior is fairly simple - an invalid argument passed into AUTH PLAIN > or > AUTH LOGIN will generate various exceptions that are uncaught by the > doAuth > method of SMTPHandler.java. They are thrown up to ha

FW: Open relay with SMTP-AUTH

All, I've just confirmed this on the latest code base. The cause is pretty obvious - there is a comment in SMTPHandler.java: // If this is a delivery failure notification (MAIL FROM: <>) // we don't enforce authentication if (authRequired && state.get(SEND

RE: Open relay with SMTP-AUTH

"MAIL FROM: <>" messages (i.e., you can't just > disable > > that). That said, messages with a null sender should not leave your > server, > > so I think it's either a conf issue or a bug in some matcher that isn't > > probably capturing that

RE: Strings to StringBuffer

All, I certainly agree that the first format Neil mentions is onerous from a readability standpoint: >StringBuffer logBuffer = new StringBuffer("text"); >logBuffer.append(var); >logBuffer.append("more text"); >logBuffer.append(anothervar); >log(logBuffer.toString()); This o

RE: Open relay with SMTP-AUTH

(or am I wrong again?). > > At least the bounces generated locally by james must leave the server (and > the bounces MUST have null sender accordingly to RFC 1123 5.3.3). > > I agree on that preventing open relay should not require adding mailets to > the default configuration fi

RE: Strings to StringBuffer

As I stated in my earlier email to the list, it should be towards the end of this week. Given the numerous issues with SMTPHandler.java, I may post that before the rest so that I can separate out potential issues. --Peter > -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROT

RE: Open relay with SMTP-AUTH

Mail(), which it sounds as if you've already noticed. > > --- Noel > > -Original Message- > From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 30, 2002 20:48 > To: 'James Developers List' > Subject: RE: Open relay with SMTP-AUTH >

RE: Open relay with SMTP-AUTH

Noel et al, I do like this suggestion - it will make James very powerful and flexible in its authentication handling. When designing these properties please remember a couple of things: i) There are a variety of SASL authentication mechanisms that may be supported in the future, so any propert

RE: IMAP changes - currently working tasks

Sascha, I, for one, am very interested in the IMAP work even if I haven't been too vocal on the list about it. Please do keep the list updated on your progress. I look forward to seeing the completed implementation. --Peter > -Original Message- > From: Sascha Kulawik [mailto:[EMAIL P

String=>StringBuffer

All, The Apache Anonymous CVS server appears to have become unresponsive while I was finishing up generating my diffs, so the changes I promised by the end of this week will be delayed. I'll probably be able to post it to the list tomorrow if the server goes back up later today or tomorrow. -

RE: [PATCH] SMTPHandler.java

All, Any thoughts, comments, critiques to this patch? I'd like to get some feedback to this and the patches I'll be submitting shortly... --Peter > -Original Message- > From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 30, 2002 11:26 PM >

[PATCH] POP3Handler.java

All, I'm submitting this one file separate from the others because the changes here are more extensive. They are similar to the changes described earlier for SMTPHandler.java. Specifically: The specific changes include: All methods and variables were documented, if only minimally. A couple

RE: [PATCH] POP3Handler.java

All, > The SMTP ID generating variable random is now static. There is > synchronized access to this variable to ensure thread safety. This clearly doesn't apply to POP3Handler.java. Just forgot to delete it when I cut, pasted, and edited my earlier message about SMTPHandler.java. Please disr

[PATCH] POP3Handler.java v.2

All, Attached is a patch to the POP3Handler.java code that rolls in the String.equalsIgnoreCase change that Noel suggested. All other previously made changes were left intact. Attached is the source and diff. As always, comments, criticisms, and questions are welcome. --Peter > -Origina

RE: Synchronization Fix

Noel, > So I'll go you one further. Why not establish that calling > LinearProcessor.add(Matcher,Mailet) after calling > LinearProcessor.service() > results in an exception? Because we have to track (and deal with the synchronization of) additional state. That is, we'd need to add a volatile

[PATCH] Synchronization Fix v.3

urday. --Peter > -Original Message- > From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 08, 2002 11:01 AM > To: 'James Developers List' > Subject: [PATCH] Synchronization Fix v.2 > > > All, > > Here's rev 2 of the

RE: Feedback IMAP

break the system, but aren't > > there ways to do this without waiting for the committers to go through > > the code thoroughly (no critic on them, they do a great work but maybe > > are a bit too busy for the moment)? > > > > Aren't there some tests (ala XP) that

RE: [PATCH] 2. attempt - FAQ - How to remove unneeded services like NNTP,POP?

Committed with a couple of minor mods (james=>James, POP=>POP3) --Peter > -Original Message- > From: Steve Short [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 10:42 AM > To: James Developers List > Subject: RE: [PATCH] 2. attempt - FAQ - How to remove unneeded services > li

Random Version Question Time

All, Here's a random question. What version Java is required to run James? And where is this information documented on the web site? I can't seem to find that information. My personal guess would be that Java 1.3 or greater is required. As this affects both users (since they must have the JV

RE: memory leak in scheduler in 2.0a3, is this fixed?

Hontvari, Some more detail here would really help. A link to the messages in the mail archive you mention would be great. Whether or not this issue has been addressed, I personally don't feel that we're in a position to release a new version. There is some substantial bug fixing to be done (c

RE: Random Version Question Time

Danny et al, Sorry about that. Don't know how I missed it. :) So the answer is Java 1.3 --Peter > -Original Message- > From: Danny Angus [mailto:[EMAIL PROTECTED]] > Sent: Sunday, August 11, 2002 2:06 AM > To: James Developers List; [EMAIL PROTECTED] > Subject: RE: Random Version Qu

[PATCH] Removing depencies on Phoenix Block Context

All, Attached is a patch that removes the dependency on the Phoenix BlockContext class. Rather than using the getBaseDirectory method of the BlockContext, we simply call get on the base Context interface with the appropriate key. The Avalon folks are still working on straightening all of this

RE: Avalon feedback request

Stephen, > 2. Declare you depedency on the framework as an extension jar dependency. > The current avalon-framework.jar (Avalon current CVS build) includes > this. If the jar files created by James include extension depedencies > your can get more rigerouse about version control.

RE: [VOTE] Should we remove ant? (was RE: Phoenix 4.0 beta)

Assuming that the requirement is documented on the web page (including required ant version) I'll give that yea vote. +1 from me (with above caveat) --Peter > -Original Message- > From: Danny Angus [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 13, 2002 11:41 AM > To: James Develop

RE: Contribution: Re: Handlers' streams RE: [Bug 11235]

All, I'm going to be taking these files, making some alterations to bring them into line with James code standards, and basically getting them in the standard form for submission. In addition to these modifications, I will be unifying all of the server/handlers under this connection paradigm.

RE: sqlResources.xml - incorrect sizes

Noel, I agree with the change. Just check the IMAP RFC before you set that username size - we don't want to do this twice. If a vote is required, consider this a +1. --Peter > -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 15, 2002 2:32

RE: [PATCH] AvalonUsersStore.java/JamesSpoolManager.java/GenericListserv.java

All of these have been committed... --Peter > -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 16, 2002 9:28 AM > To: James-Dev Mailing List > Subject: [PATCH] > AvalonUsersStore.java/JamesSpoolManager.java/GenericListserv.java > > Part 1: >

FW: What do we need to release 2.1?

All, Apologies for the cross-post folks - this was supposed to go to james-dev, not james-user. --Peter -Original Message- From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] Sent: Friday, August 16, 2002 1:56 PM To: 'James Users List' Subject: What do we need to release

RE: What do we need to release 2.1?

Jerry, > Include the changes that Peter, Shilpa, Steve, et. al made to increase > throughput to the LinearProcessor, JamesSpoolManager, and SMTPHandler. Already in the code base. > A fix for the memory leak (DefaultTimeScheduler), even if it's not the > final solution. I concur. --Peter

RE: Open relay with SMTP-AUTH

gt; > practices to accept "MAIL FROM: <>" messages (i.e., you can't just > disable > > that). That said, messages with a null sender should not leave your > server, > > so I think it's either a conf issue or a bug in some matcher that isn't > &

RE: about javadocs (was: Re: FW: What do we need to release 2.1?)

or developers. I view 2.1 as a RELEASE build for users. > Yes, > > we need to work on the javadocs, but I would not wait for them before > > putting out a stable release build if we can do so. > > > Peter M. Goldstein wrote: > > >Internal Documentation > > >

RE: address-literal addressing not working

Danny et al, I'm leaning towards Noel's reading of this. How strong are your objections? I don't want to commit anything before we have a consensus. --Peter > -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > Sent: Saturday, August 17, 2002 3:47 PM > To: James D

RE: address-literal addressing not working

Danny, > Medium :) > > Because to do it right you'd need to make sure you could match all the IP > addresses a machine is accepting, and in both forms (with and without []) > I don't think it is such simple matter to correctly identify all the > addresses, whereas it is common practice to confi

Jakarta James Nightly Build

To more knowledgeable heads than I, Noel and I have been looking at the nightly build process and are a little disturbed by the fact that: i) It is failing ii) It is failing without notifying james-dev See the nightly build report here: http://jakarta.apache.org/builds/gump/latest/jakarta-jam

RE: Configuration: "[postmaster|root]@localhost"

Noel et al, I definitely like this change. --Peter > -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 19, 2002 6:17 PM > To: James-Dev Mailing List > Subject: Configuration: "[postmaster|root]@localhost" > > The default configuration (yeah,

RE: Configuration: "[postmaster|root]@localhost"

Danny, > No, root@localhost is a reasonable default email address, it is a real > email > address, it refers to a real account on a real machine. > That AOL, and many others apache included, won't accept mail from > unreturnable addresses is neither here nor there. I very much disagree with thi

FW: A question about Phoenix security policies...

t from the environment.xml. --Peter -Original Message- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 25, 2002 2:16 PM To: Avalon Applications Developers List Subject: Re: A question about Phoenix security policies... On Mon, 26 Aug 2002 03:27, Peter M. Golds

Vacation

All, I'm going on vacation and won't have access to email, so I won't be responding to issues on james-dev this week. I'll be back next Monday. Have a good week. --Peter

RFC 2822 Header Name Unification

All,   Attached is a patch that is intended to reduce the use of “magic strings” in the James source code (it is the first of several such patches).   This patch adds all header names explicitly specified in RFC 2822 as static constants in the MailHeaders class.  The header names explic

RE: cvs commit: jakarta-james/src/java/org/apache/james James.java

Danny, (thank you) I've got no problem with that change. Your version looks clearer to me. --Peter > -Original Message- > From: Danny Angus [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, September 11, 2002 1:42 AM > To: James Developers List > Subject: RE: cvs commit: jakarta-james/src

RE: RFC 2822 Header Name Unification

Unification > > +1, suggest use classname "RFC822StringConstants" to make it clearer. > -Original Message- > From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] > Sent: 11 September 2002 09:46 > To: 'James Developers List' > Subject: RFC

RE: Adding a header field to a MimeMessage

Chris, This seems like a handy mailet. Attached is a somewhat modified version of your code. Comments have been added, and the formatting has been adjusted to be consistent with the rest of the code. Also, the configuration parameter "header" has been changed to "name" as the header usually r

RE: File Removal

ed for the imap build. > Maybe you should put them in the proposal directory with the other imap > stuff. > > Also, have you guys checked out maven > (http://jakarta.apache.org/turbine/maven/)? It should simplify > maintenance of the build system a little. > Thanks, > >

RE: File Removal

s Developers List > Subject: Re: File Removal > > But, does it work? ;) Thanks a lot Peter. I'll be testing it a little... > > Regards, > > Dan > > Peter M. Goldstein wrote: > > >Sorry about that, you are correct. I did the IMAP build first, then > &g

Phoenix and James

All, Are we up to date on Phoenix, or are we using an out-of-date version? If the latter, are there changes we need to make to the James code (i.e. Composable->Serviceable) before we can migrate to the newly release Phoenix 4.0? --Peter -- To unsubscribe, e-mail:

RE: RemoteManager : Could not open a connection to host: Connect fail

Amin, Sorry about not incorporating your patch - there are a bunch of issues here that I'm in the midst of addressing. This particular issue is handled by replacing DefaultConnectionManager with a newly built ConnectionManager implementation. I'm pretty sure the issue you're running into is ac

RE: Latest CVS Broken

Danny, I'm still getting errors when I attempt to startup James off the latest CVS version. I'm getting a NoClassDefFoundError on org.apache.mailet.MailetContext. The reason for this is pretty clear - you wiped out the Javamail classes from the sar and moved the mailet.jar build to after the S

RE: cvs commit: jakarta-james/proposals/sasl - New directory

Danny, The point was to unify the proposals under a single directory. I moved the proposal/sasl code (two Java files) under proposals/sasl --Peter > -Original Message- > From: Danny Angus [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 24, 2002 12:03 AM > To: James Developers Li

RE: [PATCH] Replace Components with Services

Steve, Have the Avalon folks made the relevant updates to the cornerstone classes and produced a corrected cornerstone.jar? --Peter -Original Message- From: Steve Short [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 10:46 AM To: [EMAIL PROTECTED] Subject: [PAT

RE: [PATCH] Replace Components with Services

Steve, As we've discussed before on the james-dev list, it's a little more indepth than this patch addresses. i) The Mailet API is to remain invariant - that is, mailets must be able to access the same components as previously using the component manager that was provid

RE: [PATCH] Replace Components with Services

All, Ok, we have a problem. Switch to Serviceable or not? How to do so? One option is to switch to Serviceable completely. Remove the ComponentManager from the Mailet API and replace it with a ServiceManager. One for one replacement. But this seems to miss the whole point of deprecating.

RE: [PATCH] Replace Components with Services

Paul, > With the greatest of respect, your users are far smaller in number that > those to say Servlet (or those to say jdbc - a real balls-up of > backwards compatability) I absolutely agree with you. But it doesn't really matter. We haven't given any notice to our user base, no matter how s

RE: [PATCH] Replace Components with Services

+1 from me. --Peter > -Original Message- > From: Paul Hammant [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 24, 2002 3:30 PM > To: James Developers List > Subject: Re: [PATCH] Replace Components with Services > > Folks, > > >+1 from me, > >I tried it at home, but straight off

Re: cvs commit: jakarta-james/proposals/imap build.xml

Sascha, I think build-test.xml is way out of date, so I doubt that that is working. Running "build -buildfile proposals/imap/build.xml" from the root directory builds the IMAP code and distribution for me. --Peter > -Original Message- > From: Sascha Kulawik [mailto:[EMAIL PROTECTED]]

RE: [PATCH] Replace Components with Services

Steve, > It is an unfortunate situation, but I think the path that will cause the > least pain now and in the future is to bite the bullet and do it. There > aren't too many mailets that use a ComponentManager / ServiceManager and > for those the code change is trivial. But that's exactly the q

RE: [PATCH] Replace Components with Services

replace ComponentManager with SystemManager. I do not think is as > big a deal as you do. > > Steve > > > -Original Message- > > From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, September 24, 2002 4:05 PM > > To: 'James Dev

Re: [PATCH] Replace Components with Services

e to change this behavior, but that's how it works today. --Peter > -Original Message- > From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 24, 2002 5:10 PM > To: James Developers List > Subject: Re: [PATCH] Replace Components with Services

RE: [PATCH] Replace Component Classes with Service Equivalents

> > Nahh, nobody is bitter, keep it up dude. Activity like this is good :-) > > Absolutely! > > A major thing that Open Source projects have going for them is, at least > in > theory, DISCUSSION. It is incidents like this that help drive or validate > a > design. Agreed. :) Thanks Steve.

RE: [PATCH] Replace Component Classes with Service Equivalents

Paul, > 1) Take the hit convert ComponentManager to ServiceManager > > - Three mailets affected > - Some contention that they are non-mailet spec anyway. With all due respect, I'm going to have to say that you are again missing the point. It's not three mailets affected. It's a totally

RE: Phoenix 4.0 final pushed up.

Steve, > I tried this with a clean checkout and build and I'm afraid it doesn't > work. I think you need to move mailet.jar back into the james.sar file, > path SAR-INF/lib. No, you don't. I resolved that problem the other day to deal with the broken build, mailet classes are now included in

RE: [PATCH] Replace Component Classes with Service Equivalents

Paul, > * James has no hot-install mailet capability yet. > * There is nor MAILET-APPS dir nor MAILET-INF/ dir in mailet using jars. > * Your user community are developers not users. > * Developers are recompile savvy and there a 1000 times less of them > that there are for deployments of the se

RE: [PATCH] Replace Component Classes with Service Equivalents

:[EMAIL PROTECTED]] > Sent: Wednesday, September 25, 2002 3:29 PM > To: James Developers List > Subject: Re: [PATCH] Replace Component Classes with Service Equivalents > > Hi, > > On Thu, 26 Sep 2002 07:59, Peter M. Goldstein wrote: > > > 1) Take the hit convert Componen

RE: Class loading

> >AvalonMailStore.java: reply = (MailRepository) > >Class.forName(repClass).newInstance(); Got this one. > >AvalonUsersStore.java: UsersRepository rep = (UsersRepository) > >Class.forName(repClass).newInstance(); Got this one. > >JdbcDataSource.java: Class.forName(jdbcDriver, true, > >Threa

Re: Build failure

I had the same problem. Upgrading to Ant 1.5 resolved it. --Peter --- "Noel J. Bergman" <[EMAIL PROTECTED]> wrote: > cvs update -Pd > ./build.sh clean > ./build.sh > > Result: > > BUILD FAILED > > /home/noel/jakarta/jakarta-james/build.xml:366: > Could not create task of > type: sar due to

Re: cvs commit: jakarta-james/proposals/imap build.xml

Sascha, > what is missing for getting IMAP in the Main Trunk > by default as disabled > (and maked unstable) ? IMHO the following issues need to be addressed before we can vote the IMAP code into the main branch: i) Conclusive summary of what does and does not work that can be posted on the we

RE: cvs commit: jakarta-james build.xml

Steve, > Question: are the other comitters running James before comitting their > changes to CVS? I don't mean this in a critical, negative way, and I > know it is easy to have jars lying around so stuff still works until you > do a cleanup, but when the Phoenix server doesn't even startup I f

[PATCH] DBFile functionality, bug #12031

All, This patch is designed to resolve an ordering issue in the code. In DBFile mode, the code looks for a parameter before it can possibly be initialized. This means that DBFile mode never works. The patch attached resolves this initialization ordering issue, although there still may be othe

Release Plan

My first copy of this email didn't seem to go through, so I'm resending... This is a proposed release plan for the 2.1 release. The primary goal of this plan is to get a stable, scalable, and functional James 2.1 out in October, and allow the developers as a group to move on to a discussion of

RE: cvs commit: jakarta-james build.bat

Danny, > ant does this at build. Yes, I know. Which is why it's annoying to see that constant diff after I run a build. We had this discussion the last time Paul checked in a new Phoenix - he did the same thing at that time. --Peter -- To unsubscribe, e-mail:

Aliasing

All, The aliasing implementation in James appears to be backwards. An alias is an "additional name" (see www.m-w.com). So what you'd expect is that mails sent to an alias would be delivered to the base username. But in fact, if you set things up following the docs in the RemoteManagerHandler

[PROPOSAL] Release Plan for 2.1

This is a proposed release plan for the 2.1 release. The primary goal of this plan is to get a stable, scalable, and functional James 2.1 out in October, and allow the developers as a group to move on to a discussion of future releases. Relevant Dates: Feature Freeze: 10/3/02 Code Freeze: 10/

RE: Aliasing

Noel, > I wouldn't change this right now, other than to clarify the documentation. > The user repository can be (and should be) revisited post-2.1 release. Ok. We'll leave it for now and revisit after 2.1 release. --Peter -- To unsubscribe, e-mail: For addition

RE: Release Plan

Danny, > > 2) Change code so that it doesn't use the TimeScheduler in the assorted > > server blocks (excluding the newly introduced FetchPOP) > > Sorry, slightly off the topic of this thread, whats wrong with > TimeScheduler, and why is it OK for fetchpop, have I missed something? TimeSchedul

RE: Release Plan

Steve, > Is it the the memory leak due to Cornerstone creating new entries on > it's task list but not clearing them up until they 'expire'? > > http://issues.apache.org/bugzilla/show_bug.cgi?id=9275 > http://www.mail-archive.com/james-dev@jakarta.apache.org/msg02938.html Yep, that's part of i

RE: cvs commit: jakarta-james build.sh

Noel, > No. The ant script is broken with respect to locating ANT_HOME as a > relative entity. They restore the path AFTER they try to cd with a > relative > path, instead of before, so they are in the wrong directory when they > issue > the cd. > > Please rollback this change, and submit the

[PATCH] Assorted RemoteManager fixes

All, The attached patch is designed to resolve a number of issues with the RemoteManager. The following changes were incorporated: i) Extensive commenting ii) Refactoring of code to standardize handler method interfaces, isolate string constants iii) Corrected erroneous usage statements iv) Ad

RE: cvs commit: jakarta-james build.bat

Paul, > Couls you clarify what I am being accused of. You're not "being accused of" anything. It's very simple, and clearly laid out in the thread. You committed an essentially unchanged build.bat (see your last commit) and you actually did the same thing once before (check the history of th

  1   2   3   >