Re: [VOTE] Wiring/Dependencies/Lifecycle Management for next James
On 21/07/06, Stefano Bagnara [EMAIL PROTECTED] wrote: I think it worked, I will try to use this kind of messages in future, and I'll use the POLL identifier so everyone will be happy. Cool, I think it worked too. [VOTE] has a special meaning, [VOTES] record concrete decisions we've made, using [POLL] is a good idea. If I opened 10 threads with a single discussion about each topic I bet I wouldn't have received so much answers and I now we only would have random threads with unfisnished discussions and nothing more. This is much less important for a POLL than a VOTE, I'm sure you can see that I thought this was a VOTE and was too much for a single issue. If james committer was faster in votes we could easily use a different approach. This poll is a custom solution that I decided to experiment because of lacks in the current way we were working. I think plenty of other projects use this approach, this is an OK thing to do. However don't confuse the results of the poll with a mandate to put the items into practice, it is an indication that we comfortable with the proposals but authority would only come with a VOTE. But as we practice Commit Then Review you have achieved enough to make the progress you're after. Nice work, d. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with custom documentation
Robert, add jars to /SAR-INF/lib and classes to /SAR-INF/classes once phoenix has unpacked everything. (you may need to create the dirs. Watch out though, phoenix's classpathery will sometimes mean that you may have to move stuff about to see that same classes as James does, for db connections for e.g. Normally you should be OK though, because IIRC we expose too much of the phoenix/james cp to mailets ;-) d. On 15/07/06, robert burrell donkin [EMAIL PROTECTED] wrote: http://james.apache.org/custom_mailet_2_1.html suggests that one way to get custom mailets working is to add jars to the lib directory. when i add the james and mailet jars i get: java.lang.NoClassDefFoundError: org/apache/avalon/cornerstone/services/connection/AbstractHandlerFactory on startup. looks very much like a classloader issue to me. perhaps the documentation needs to be updated. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release plans
Am Freitag, den 21.07.2006, 14:20 -0400 schrieb Noel J. Bergman: Stefano, 1) 2.3 is release candidate: we don't change anything if not to fix major/medium bugs We are agreed. So let's leave v2.3 alone, and talk about v2.4. 2) 2.4 is the next 2.x release (we had this in roadmap until you decided at apachecon to keep only 3.0 ;-) ) and is storage compatible with 2.2 (like 2.3). We're on the same page, right up to here: We can backport here *anything* from trunk if we keep storage compatibility and mailet api compatibility. Yes, we CAN, but I don't know that we WANT to. I listed a few relatively low-risk, high-value items to make the difference between v2.3 and v2.4. I am not willing to say *anything* without agreeing on what each thing would be. v2.4 should NOT be a major development, but only low-risk, high-value additions to v2.3 while we focus on v3 (trunk). Currently IIRC anything we have in trunk could be part of the 2.4 release as we didn't introduce any incompatibility. But did we introduce any benefit? List the changes that you want to handle, and we can talk about it. FetchMail, for example, I would say no. Why not? Because my recollection is that there is no benefit to the new code other than it being a bit cleaner in your view (not making a personal judgment of my own). And, as we have all seen during the v2.3 beta phase, even the most innocent of changes can create defects. So I maintain the v2.4 concept: low-risk, high-value - no value, no change. If we want to follow this roadmap I would avoid to commit anything 3.0 specific in trunk until we have a 2.3.0 final out. Then I would start a 2.4.0 branch from the trunk of that moment and from that point we would still have 2 active tree (2.4 branch and trunk for 3.0). I would not. Instead, I would rename the v2.3 branch to v2.4, after creating the v2.3 tag. I would have no intention of maintaining v2.3.x separately. v2.4 would be the maintanence for v2.3. And trunk would be the next major release. Im not 100 % sure that is the best way.. I whould try to get the 2.3 final first and close the 2.3 branch after that. Then we should copy the 2.3 to 2.4 and dediced what we want to have in 2.4 and copy the stuff from trunk. I think we could put and should put more then fastfail and launcher in 2.4. Maybe support fastfail also in RemoteManager and Pop3 server ? However, if someone wants to enumerate the code changes between v2.3 and trunk, and make a case for each one, I'm willing for us all to risk assess them. And if the final view is that using trunk for v2.4 is correct, then that's what we'll do. About your specific proposal (having a 2.4 as a 2.3+fast fail+launcher) I'm currently -1 because I think fast fail need much more work and the launcher is to be tested and there is much more that deserve inclusion in a 2.4 release before (almost all we currently have in trunk). Launcher is optional. And without the revised fast-fail, there is no reason to have a v2.4. --- Noel bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Mailet SDK...?
Mornin.. Am Samstag, den 22.07.2006, 10:00 +0100 schrieb robert burrell donkin: On 7/22/06, Danny Angus [EMAIL PROTECTED] wrote: Mornin' Robert, mornin' Danny (been in Ibiza!) cool - or more accurately - hot :-) IMHO what's needed is a template development environment complete with ant build script, cut down james configuration (developers shouldn't be running development code on the standard ports) and some sample code. i'm probably going to need to develop something similar for my own purposes. if there's interest i'd be happy to post a patch to JIRA. You're right the SDK was meant to be that, but we got so bogged down in Avalon issues it never really got finished. One idea I had for it was that it would be possible to start a minimal james which would take its input from ascii files (mbox/maildir possibly) and just pump them through the mailet pipeline so that mailet applications could become testable without invoking all the other bits of james. sounds good (not sure whether commons-email is able to read ASCII in mbox or /maildir format ATM but that code would make a good addition to the library.) ATM i'm using a stripped down james with SMTP serving on a high with everything else stripped out. i'm using commons-email to create test messages to play around with. would probably want to move to unit testing when i get a little more serious. Maybe you want to have a look on the james source.. we allready wrote all the needed stuff to write junit test for mailets and matchers :-) i'll try to find some time to tidy up the SDK i'm using ATM and post it to JIRA as a starting point. would probably need some changes to the build script so that variable content (such as the mailet classes and the jars) were dynamically created for each release. - robert Cool .. im lookin forward to this. Thx for the work. bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
svn commit: r424545 - /james/server/trunk/phoenix-bin/bin/phoenix-daemon-loader-0.1.jar
Author: norman Date: Sat Jul 22 03:40:10 2006 New Revision: 424545 URL: http://svn.apache.org/viewvc?rev=424545view=rev Log: Remove the jar to get ready for upload a new one Removed: james/server/trunk/phoenix-bin/bin/phoenix-daemon-loader-0.1.jar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r424546 - /james/server/trunk/phoenix-bin/bin/phoenix-daemon-loader-0.1.jar
Author: norman Date: Sat Jul 22 03:42:17 2006 New Revision: 424546 URL: http://svn.apache.org/viewvc?rev=424546view=rev Log: New version of the phoenix-daemon-loader which now exit if an error detect on startup. Before the jsvc process just start without notice this Added: james/server/trunk/phoenix-bin/bin/phoenix-daemon-loader-0.1.jar (with props) Added: james/server/trunk/phoenix-bin/bin/phoenix-daemon-loader-0.1.jar URL: http://svn.apache.org/viewvc/james/server/trunk/phoenix-bin/bin/phoenix-daemon-loader-0.1.jar?rev=424546view=auto == Binary file - no diff available. Propchange: james/server/trunk/phoenix-bin/bin/phoenix-daemon-loader-0.1.jar -- svn:mime-type = application/octet-stream - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SourceCode of phoenix-daemon-loader
Hi guys,
anyone has an idea where to put the source code of
phoenix-daemon-loader ? Its just one class. So maybe a bit overkill to
create an extra svn project. Any ideas ? The code looks like this at the
moment:
/***
* Copyright (c) 1999-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.avalon.phoenix.launcher;
import org.apache.avalon.phoenix.launcher.Main;
import org.apache.commons.daemon.Daemon;
import org.apache.commons.daemon.DaemonContext;
import org.apache.commons.daemon.DaemonController;
import java.util.Hashtable;
import java.util.Observable;
import java.util.Observer;
/**
* Phoenix launcher using Commons daemon.
*/
public class CommonsDaemonLauncher implements Daemon, Observer
{
private DaemonContextm_context;
private DaemonController m_controller;
private String[] m_args;
/**
* @see org.apache.commons.daemon.Daemon#init(DaemonContext)
*/
public void init(final DaemonContext daemonContext) throws Exception
{
m_context = daemonContext;
m_controller = m_context.getController();
m_args = m_context.getArguments();
final Hashtable data = new Hashtable();
data.put(Observer.class.getName(), this);
log(init application);
// We have to call this in init cause otherwise we not able to
bind the ports!
int exitCode = Main.startup(m_args, data, false);
// Check if we should exit here cause the startup of phoenix
fails
if (exitCode == 1) {
System.exit(exitCode);
}
}
/**
* @see org.apache.commons.daemon.Daemon#start()
*/
public void start()
{
log(starting application);
}
/**
* @see org.apache.commons.daemon.Daemon#stop()
*/
public void stop()
{
Main.shutdown();
}
/**
* @see org.apache.commons.daemon.Daemon#destroy()
*/
public void destroy()
{
}
/**
* @see java.util.Observer#update(Observable, Object)
*/
public void update(final Observable observable, final Object arg)
{
final String command = (null != arg) ? arg.toString() : ;
if (command.equals(restart))
{
log(restart requested.);
m_controller.reload();
log(restart completed.);
}
else if (command.equals(shutdown))
{
log(shutdown requested.);
m_controller.shutdown();
log(shutdown completed.);
}
else
{
throw new IllegalArgumentException(Unknown action +
command);
}
}
/**
* Loggin helper
*
* @param message The message to log to the console
*/
private void log(final String message)
{
System.out.print(CommonsDaemon: );
System.out.println(message);
System.out.flush();
}
}
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
[jira] Created: (JAMES-574) Annoying logging of whitelist/blacklist nomatching as unknown host exception thrown: listname if INFO is enabled
Annoying logging of whitelist/blacklist nomatching as unknown host exception thrown: listname if INFO is enabled -- Key: JAMES-574 URL: http://issues.apache.org/jira/browse/JAMES-574 Project: James Issue Type: Bug Components: SMTPServer Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Priority: Trivial Fix For: 2.3.0rc1, 3.0 When a checkDNSRBL is done, in case getLogger().isInfoEnabled() is true, both successfull and unsuccessfull matches are being logged. While successfull matches are useful to log as INFO, the much more frequent unsuccessfull matches are logged as unknown host exception thrown: listname, heavily increasing the size of the log file. Such log message is useful only in DEBUG mode. -- 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: r424557 - /james/server/branches/v2.3/src/java/org/apache/james/smtpserver/DNSRBLHandler.java
Author: vincenzo
Date: Sat Jul 22 04:44:03 2006
New Revision: 424557
URL: http://svn.apache.org/viewvc?rev=424557view=rev
Log:
Fixing James-574: Annoying logging of whitelist/blacklist nomatching as
unknown host exception thrown: listname if INFO is enabled.
Modified:
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/DNSRBLHandler.java
Modified:
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/DNSRBLHandler.java
URL:
http://svn.apache.org/viewvc/james/server/branches/v2.3/src/java/org/apache/james/smtpserver/DNSRBLHandler.java?rev=424557r1=424556r2=424557view=diff
==
---
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/DNSRBLHandler.java
(original)
+++
james/server/branches/v2.3/src/java/org/apache/james/smtpserver/DNSRBLHandler.java
Sat Jul 22 04:44:03 2006
@@ -125,8 +125,8 @@
}
return false;
} catch (java.net.UnknownHostException uhe) {
-if (getLogger().isInfoEnabled()) {
-getLogger().info(unknown host exception thrown: +
rblList[i]);
+if (getLogger().isDebugEnabled()) {
+getLogger().debug(unknown host exception thrown: +
rblList[i]);
}
}
}
@@ -141,8 +141,8 @@
return true;
} catch (java.net.UnknownHostException uhe) {
// if it is unknown, it isn't blocked
-if (getLogger().isInfoEnabled()) {
-getLogger().info(unknown host exception thrown: +
rblList[i]);
+if (getLogger().isDebugEnabled()) {
+getLogger().debug(unknown host exception thrown: +
rblList[i]);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r424559 - /james/server/trunk/src/java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java
Author: vincenzo
Date: Sat Jul 22 04:45:26 2006
New Revision: 424559
URL: http://svn.apache.org/viewvc?rev=424559view=rev
Log:
Fixing James-574: Annoying logging of whitelist/blacklist nomatching as
unknown host exception thrown: listname if INFO is enabled.
Modified:
james/server/trunk/src/java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java
Modified:
james/server/trunk/src/java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java?rev=424559r1=424558r2=424559view=diff
==
---
james/server/trunk/src/java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java
(original)
+++
james/server/trunk/src/java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java
Sat Jul 22 04:45:26 2006
@@ -195,8 +195,8 @@
session.getConnectionState().put(RBL_BLOCKLISTED_MAIL_ATTRIBUTE_NAME, false);
return;
} catch (java.net.UnknownHostException uhe) {
-if (getLogger().isInfoEnabled()) {
-getLogger().info(IpAddress +
session.getRemoteIPAddress() + not listed on + rblList[i]);
+if (getLogger().isDebugEnabled()) {
+getLogger().debug(IpAddress +
session.getRemoteIPAddress() + not listed on + rblList[i]);
}
}
}
@@ -226,8 +226,8 @@
return;
} catch (java.net.UnknownHostException uhe) {
// if it is unknown, it isn't blocked
-if (getLogger().isInfoEnabled()) {
-getLogger().info(unknown host exception thrown: +
rblList[i]);
+if (getLogger().isDebugEnabled()) {
+getLogger().debug(unknown host exception thrown: +
rblList[i]);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-574) Annoying logging of whitelist/blacklist nomatching as unknown host exception thrown: listname if INFO is enabled
[ http://issues.apache.org/jira/browse/JAMES-574?page=all ] Vincenzo Gianferrari Pini resolved JAMES-574. - Resolution: Fixed Changed the log message level to debug when match fails. Annoying logging of whitelist/blacklist nomatching as unknown host exception thrown: listname if INFO is enabled -- Key: JAMES-574 URL: http://issues.apache.org/jira/browse/JAMES-574 Project: James Issue Type: Bug Components: SMTPServer Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 Reporter: Vincenzo Gianferrari Pini Assigned To: Vincenzo Gianferrari Pini Priority: Trivial Fix For: 2.3.0rc1, 3.0 When a checkDNSRBL is done, in case getLogger().isInfoEnabled() is true, both successfull and unsuccessfull matches are being logged. While successfull matches are useful to log as INFO, the much more frequent unsuccessfull matches are logged as unknown host exception thrown: listname, heavily increasing the size of the log file. Such log message is useful only in DEBUG mode. -- 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: r424567 - in /james/server/trunk/src: java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java test/org/apache/james/smtpserver/SMTPTestConfiguration.java
Author: norman
Date: Sat Jul 22 05:36:11 2006
New Revision: 424567
URL: http://svn.apache.org/viewvc?rev=424567view=rev
Log:
Forget to fix JAMES-566 when copy the fastfail stuff. Also fix the junit test
which was not workin
Modified:
james/server/trunk/src/java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java
Modified:
james/server/trunk/src/java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java?rev=424567r1=424566r2=424567view=diff
==
---
james/server/trunk/src/java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java
(original)
+++
james/server/trunk/src/java/org/apache/james/smtpserver/core/filter/fastfail/DNSRBLHandler.java
Sat Jul 22 05:36:11 2006
@@ -255,10 +255,9 @@
SMTPSession.CURRENT_RECIPIENT);
if (blocklisted.equals(true) // was found in the RBL
-((session.isAuthRequired() session
-.getUser() != null)) // Not (either an authorized IP
-// or (SMTP AUTH is enabled and
-// not authenticated))
+!(session.isAuthRequired() session
+.getUser() != null) // Not (SMTP AUTH is enabled and
+// not authenticated)
!(recipientAddress.getUser().equalsIgnoreCase(postmaster) ||
recipientAddress
.getUser().equalsIgnoreCase(abuse))) {
Modified:
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java?rev=424567r1=424566r2=424567view=diff
==
---
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java
(original)
+++
james/server/trunk/src/test/org/apache/james/smtpserver/SMTPTestConfiguration.java
Sat Jul 22 05:36:11 2006
@@ -18,7 +18,6 @@
package org.apache.james.smtpserver;
-import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.avalon.framework.configuration.DefaultConfiguration;
import org.apache.james.smtpserver.core.CoreCmdHandlerLoader;
@@ -151,38 +150,22 @@
DefaultConfiguration config = new DefaultConfiguration(handlerchain);
+// add the rbl handler
if (m_useRBL) {
-DefaultConfiguration handlerChain = (DefaultConfiguration)
handlerConfig
-.getChild(handlerchain);
DefaultConfiguration handler = new DefaultConfiguration(handler);
handler.setAttribute(class, DNSRBLHandler.class.getName());
handler.setAttribute(command, RCPT);
-handlerChain.addChild(handler);
-}
-// Add Configuration for Helo checks and Ehlo checks
-Configuration[] heloConfig = handlerConfig.getChild(handlerchain)
-.getChildren(handler);
-for (int i = 0; i heloConfig.length; i++) {
-if (heloConfig[i] instanceof DefaultConfiguration) {
-String cmd = ((DefaultConfiguration) heloConfig[i])
-.getAttribute(command, null);
-if (cmd == null) {
-String className = ((DefaultConfiguration) heloConfig[i])
-.getAttribute(class, null);
-
-if (DNSRBLHandler.class.getName().equals(className)) {
-DefaultConfiguration d = (DefaultConfiguration)
heloConfig[i];
-
-DefaultConfiguration blacklist = new
DefaultConfiguration(
-blacklist);
-blacklist.setValue(bl.spamcop.net);
-DefaultConfiguration rblServers = new
DefaultConfiguration(
-rblservers);
-rblServers.addChild(blacklist);
-d.addChild(rblServers);
-}
-}
-}
+
+DefaultConfiguration blacklist = new DefaultConfiguration(
+blacklist);
+blacklist.setValue(bl.spamcop.net);
+DefaultConfiguration rblServers = new DefaultConfiguration(
+rblservers);
+rblServers.addChild(blacklist);
+
+handler.addChild(rblServers);
+config.addChild(handler);
+
}
config.addChild(createHandler(CoreFilterCmdHandlerLoader.class
[jira] Updated: (JAMES-500) Use Commons Daemon to start james
[ http://issues.apache.org/jira/browse/JAMES-500?page=all ] Norman Maurer updated JAMES-500: Attachment: phoenix-daemon-loader-0.1.jar Current version as jar Use Commons Daemon to start james - Key: JAMES-500 URL: http://issues.apache.org/jira/browse/JAMES-500 Project: James Issue Type: Improvement Reporter: Norman Maurer Assigned To: Norman Maurer Fix For: 3.0 Attachments: commonsdaemonlauncher.jar, CommonsDaemonLauncher.java, CommonsDaemonLauncher.java, CommonsDaemonPhoenixLauncher.java, phoenix-daemon-loader-0.1.jar, phoenix-loader.jar We should figure out how to use Commons Daemon ( http://jakarta.apache.org/commons/daemon/ ) to start james. So we could run james as non root on privilege ports. Thx noel for pointing this out on mailling list. -- 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] Resolved: (JAMES-500) Use Commons Daemon to start james
[ http://issues.apache.org/jira/browse/JAMES-500?page=all ] Norman Maurer resolved JAMES-500. - Resolution: Fixed Use Commons Daemon to start james - Key: JAMES-500 URL: http://issues.apache.org/jira/browse/JAMES-500 Project: James Issue Type: Improvement Reporter: Norman Maurer Assigned To: Norman Maurer Fix For: 3.0 Attachments: commonsdaemonlauncher.jar, CommonsDaemonLauncher.java, CommonsDaemonLauncher.java, CommonsDaemonPhoenixLauncher.java, phoenix-daemon-loader-0.1.jar, phoenix-loader.jar We should figure out how to use Commons Daemon ( http://jakarta.apache.org/commons/daemon/ ) to start james. So we could run james as non root on privilege ports. Thx noel for pointing this out on mailling list. -- 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-569) Add Support for POP-before-SMTP (roaming users)
[ http://issues.apache.org/jira/browse/JAMES-569?page=all ] Norman Maurer reassigned JAMES-569: --- Assignee: Norman Maurer Add Support for POP-before-SMTP (roaming users) --- Key: JAMES-569 URL: http://issues.apache.org/jira/browse/JAMES-569 Project: James Issue Type: New Feature Reporter: Norman Maurer Assigned To: Norman Maurer Fix For: 3.0 We should add support for pop-before-smtp. This is a common and often used technic to authenticate users before allow them to send an email to an external address. -- 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: SourceCode of phoenix-daemon-loader
Norman Maurer wrote: Hi guys, anyone has an idea where to put the source code of phoenix-daemon-loader ? Its just one class. So maybe a bit overkill to create an extra svn project. Any ideas ? The code looks like this at the moment: At the moment I would add the file source to the JAMES_PHOENIX.txt file that already explain the process to obtain our custom phoenix binary. This is not a best practice but I wouldn't like to add a phoenix class to james server source repository. One furthe option would be to create our own branch of phoenix under james and put there the changes described in JAMES_PHOENIX.txt plus this class. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r424576 - /james/server/trunk/src/site/
Author: bago Date: Sat Jul 22 06:51:58 2006 New Revision: 424576 URL: http://svn.apache.org/viewvc?rev=424576view=rev Log: Prepare folder structure for site doc changes Added: james/server/trunk/src/site/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r424578 - in /james/server/trunk/src: site/xdoc/ xdocs/
Author: bago Date: Sat Jul 22 06:57:19 2006 New Revision: 424578 URL: http://svn.apache.org/viewvc?rev=424578view=rev Log: Prepare folder structure for site doc changes Added: james/server/trunk/src/site/xdoc/ - copied from r424577, james/server/trunk/src/xdocs/ Removed: james/server/trunk/src/xdocs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r424581 - in /james/server/trunk: ./ src/site/ src/site/resources/ src/site/resources/css/ src/site/resources/images/ src/site/xdoc/ src/site/xdoc/images/
Author: bago
Date: Sat Jul 22 07:23:20 2006
New Revision: 424581
URL: http://svn.apache.org/viewvc?rev=424581view=rev
Log:
Updated site documentation to match maven2 folder structure.
Updated build.xml to find the xdocs in the new place.
Created a pom.xml and site.xml to be able to create server site with the
shared look using mvn site (JAMES-573, JAMES-571, JAMES-432)
Added:
james/server/trunk/pom.xml (with props)
james/server/trunk/src/site/resources/
james/server/trunk/src/site/resources/css/
james/server/trunk/src/site/resources/css/site.css (with props)
james/server/trunk/src/site/resources/images/
james/server/trunk/src/site/resources/images/asf-logo-reduced.gif (with
props)
james/server/trunk/src/site/resources/images/button-bottom.gif (with
props)
james/server/trunk/src/site/resources/images/button-top.gif (with props)
james/server/trunk/src/site/resources/images/collapsed.gif (with props)
james/server/trunk/src/site/resources/images/expanded.gif (with props)
james/server/trunk/src/site/resources/images/external.png (with props)
james/server/trunk/src/site/resources/images/h2feather.gif (with props)
james/server/trunk/src/site/resources/images/h4.jpg (with props)
james/server/trunk/src/site/resources/images/icon_error_sml.gif (with
props)
james/server/trunk/src/site/resources/images/icon_info_sml.gif (with
props)
james/server/trunk/src/site/resources/images/icon_success_sml.gif (with
props)
james/server/trunk/src/site/resources/images/icon_warning_sml.gif (with
props)
james/server/trunk/src/site/resources/images/james-server-logo.gif (with
props)
james/server/trunk/src/site/resources/images/james_config_load_balance.png
(with props)
james/server/trunk/src/site/resources/images/james_config_secondary.png
(with props)
james/server/trunk/src/site/resources/images/james_config_smart_host.png
(with props)
james/server/trunk/src/site/resources/images/newwindow.png (with props)
james/server/trunk/src/site/resources/images/void.gif (with props)
james/server/trunk/src/site/site.xml (with props)
james/server/trunk/src/site/xdoc/images/james-logo.jpg (with props)
james/server/trunk/src/site/xdoc/images/james_config_load_balance.png
(with props)
james/server/trunk/src/site/xdoc/images/james_config_secondary.png (with
props)
james/server/trunk/src/site/xdoc/images/james_config_smart_host.png (with
props)
Modified:
james/server/trunk/default.properties
james/server/trunk/src/site/xdoc/changelog.xml
james/server/trunk/src/site/xdoc/images/void.gif
james/server/trunk/src/site/xdoc/index.xml
Modified: james/server/trunk/default.properties
URL:
http://svn.apache.org/viewvc/james/server/trunk/default.properties?rev=424581r1=424580r2=424581view=diff
==
--- james/server/trunk/default.properties (original)
+++ james/server/trunk/default.properties Sat Jul 22 07:23:20 2006
@@ -1,4 +1,4 @@
-# ---
+s# ---
# B U I L D P R O P E R T I E S
# ---
# Specifies default property values
@@ -69,7 +69,7 @@
java.dir=${src.dir}/java
junitjava.dir=${src.dir}/test
conf.dir=${src.dir}/conf
-xdocs.dir=${src.dir}/xdocs
+xdocs.dir=${src.dir}/site/xdoc
docs.src=${xdocs.dir}
constants.file = org/apache/james/Constants.java
poolconn.file = org/apache/james/util/mordred/PoolConnEntry.java
Added: james/server/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/james/server/trunk/pom.xml?rev=424581view=auto
==
--- james/server/trunk/pom.xml (added)
+++ james/server/trunk/pom.xml Sat Jul 22 07:23:20 2006
@@ -0,0 +1,61 @@
+?xml version=1.0 encoding=UTF-8?
+project
+ modelVersion4.0.0/modelVersion
+ groupIdorg.apache.james/groupId
+ artifactIdjames-server/artifactId
+ nameApache James Server/name
+ version1/version
+ description
+Apache James Server
+ /description
+ urlhttp://james.apache.org/server/url
+ inceptionYear2006/inceptionYear
+
+ dependencies
+ /dependencies
+
+ organization
+nameApache Software Foundation/name
+urlhttp://www.apache.org/url
+ /organization
+
+ licenses
+license
+ nameApache License, Version 2.0/name
+ urlhttp://www.apache.org/licenses/LICENSE-2.0.html/url
+ distributionrepo/distribution
+/license
+ /licenses
+
+ issueManagement
+systemJIRA/system
+urlhttp://issues.apache.org/jira/browse/JAMES/url
+ /issueManagement
+
+ scm
+connection
+ scm:svn:http://svn.apache.org/repos/asf/james/server/trunk
+/connection
+developerConnection
+ scm:svn:https://svn.apache.org/repos/asf/james/server/trunk
+
svn commit: r424583 - /james/server/trunk/src/site/xdoc/images/
Author: bago Date: Sat Jul 22 07:26:08 2006 New Revision: 424583 URL: http://svn.apache.org/viewvc?rev=424583view=rev Log: Updated site documentation to match maven2 folder structure. Updated build.xml to find the xdocs in the new place. Created a pom.xml and site.xml to be able to create server site with the shared look using mvn site (JAMES-573, JAMES-571, JAMES-432) Removed: james/server/trunk/src/site/xdoc/images/asf-logo-reduced.gif james/server/trunk/src/site/xdoc/images/button-bottom.gif james/server/trunk/src/site/xdoc/images/button-top.gif james/server/trunk/src/site/xdoc/images/collapsed.gif james/server/trunk/src/site/xdoc/images/expanded.gif james/server/trunk/src/site/xdoc/images/external.png james/server/trunk/src/site/xdoc/images/h2feather.gif james/server/trunk/src/site/xdoc/images/h4.jpg james/server/trunk/src/site/xdoc/images/icon_error_sml.gif james/server/trunk/src/site/xdoc/images/icon_info_sml.gif james/server/trunk/src/site/xdoc/images/icon_success_sml.gif james/server/trunk/src/site/xdoc/images/icon_warning_sml.gif james/server/trunk/src/site/xdoc/images/james-jspf-logo.gif james/server/trunk/src/site/xdoc/images/newwindow.png - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JAMES-574 -- which version?
Vincenzo Gianferrari Pini Resolution: Fixed Changed the log message level to debug when match fails. Key: JAMES-574 URL: http://issues.apache.org/jira/browse/JAMES-574 Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 Fix For: 2.3.0rc1, 3.0 Uh ... we already voted on and tagged RC1, right? Are we going to re-roll RC1, or update JIRA to show this in RC2? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES-574 -- which version?
Noel J. Bergman wrote: Vincenzo Gianferrari Pini Resolution: Fixed Changed the log message level to debug when match fails. Key: JAMES-574 URL: http://issues.apache.org/jira/browse/JAMES-574 Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 Fix For: 2.3.0rc1, 3.0 Uh ... we already voted on and tagged RC1, right? Are we going to re-roll RC1, or update JIRA to show this in RC2? --- Noel IMO this should have not been applied to 2.3 branch. We are in RC and we should apply only fixes to critical things. This is not really a bug, only an annoiance. We should put this stuff in 2.3.1 or 2.4 Otherwise we should change our current 2.3 policy, and we should have not used the rc tag. If we start applying similar changes I don't see why we shouldn't apply http://issues.apache.org/jira/browse/JAMES-515 Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES-574 -- which version?
I disagree. It was a bug, though trivial. And one year ago the behaviour was like now after the fix (at least at info log level). And if we find a bug, even not critical, whose fix is trivial, it can and should be applied even to RC. I would otherwise yesterday have voted -1 to [VOTE] James 2.3.0rc1 Release, as it's been two weeks that I said that I was going to test this weekend in my production system. And JAMES-515 is not a fix to a bug, simply a cleanup that could introduce problems to existing customers, and no perceived functional advantage. Vincenzo Stefano Bagnara wrote: Noel J. Bergman wrote: Vincenzo Gianferrari Pini Resolution: Fixed Changed the log message level to debug when match fails. Key: JAMES-574 URL: http://issues.apache.org/jira/browse/JAMES-574 Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 Fix For: 2.3.0rc1, 3.0 Uh ... we already voted on and tagged RC1, right? Are we going to re-roll RC1, or update JIRA to show this in RC2? --- Noel IMO this should have not been applied to 2.3 branch. We are in RC and we should apply only fixes to critical things. This is not really a bug, only an annoiance. We should put this stuff in 2.3.1 or 2.4 Otherwise we should change our current 2.3 policy, and we should have not used the rc tag. If we start applying similar changes I don't see why we shouldn't apply http://issues.apache.org/jira/browse/JAMES-515 Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES-574 -- which version?
I also see no problems to this in rc1.. i can reroll the release or put it in rc2 .. +1 for rc2 +0 rc1 bye Norman Am Samstag, den 22.07.2006, 19:55 +0200 schrieb Vincenzo Gianferrari Pini: I disagree. It was a bug, though trivial. And one year ago the behaviour was like now after the fix (at least at info log level). And if we find a bug, even not critical, whose fix is trivial, it can and should be applied even to RC. I would otherwise yesterday have voted -1 to [VOTE] James 2.3.0rc1 Release, as it's been two weeks that I said that I was going to test this weekend in my production system. And JAMES-515 is not a fix to a bug, simply a cleanup that could introduce problems to existing customers, and no perceived functional advantage. Vincenzo Stefano Bagnara wrote: Noel J. Bergman wrote: Vincenzo Gianferrari Pini Resolution: Fixed Changed the log message level to debug when match fails. Key: JAMES-574 URL: http://issues.apache.org/jira/browse/JAMES-574 Affects Versions: 2.3.0b3, 2.3.0b2, 2.3.0b1, 2.3.0a3, 2.3.0a2, 2.3.0a1, 3.0 Fix For: 2.3.0rc1, 3.0 Uh ... we already voted on and tagged RC1, right? Are we going to re-roll RC1, or update JIRA to show this in RC2? --- Noel IMO this should have not been applied to 2.3 branch. We are in RC and we should apply only fixes to critical things. This is not really a bug, only an annoiance. We should put this stuff in 2.3.1 or 2.4 Otherwise we should change our current 2.3 policy, and we should have not used the rc tag. If we start applying similar changes I don't see why we shouldn't apply http://issues.apache.org/jira/browse/JAMES-515 Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !EXCUBATOR:1,44c266bc43381548542968! signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [VOTE] James 2.3.0rc1 Release
Norman Maurer wrote: i just build,sign and upload james 2.3.0rc1. You can grab it from: http://people.apache.org/~norman/james/ so plz test and cast your votes.. +1 Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAMES-574 -- which version?
I don't agree with Vincenzo about what is a bug and what could introduce problems, btw this is a matter of personal views, so here is my vote: -1 to reroll rc1: we already have the tag and an in-progress vote/test (i did this once, we already agreed this was a mistake, so try to not repeat this). -0 to apply the patch for the next rc: i think we could live we a debug logged as info in experimental code (disabled by default) So I'm not vetoing it, but I'll change it to +1 if we'll find much more bugs in RC1 and we'll have a longer release cycle for the next rc/tests. Imho it does not make sense to create a new release for a log change and delay even if few days our rc1 release, but I'm not the one that prepare releases and I can't know if this will really delay things. Stefano Norman Maurer wrote: I also see no problems to this in rc1.. i can reroll the release or put it in rc2 .. +1 for rc2 +0 rc1 bye Norman Am Samstag, den 22.07.2006, 19:55 +0200 schrieb Vincenzo Gianferrari Pini: I disagree. It was a bug, though trivial. And one year ago the behaviour was like now after the fix (at least at info log level). And if we find a bug, even not critical, whose fix is trivial, it can and should be applied even to RC. I would otherwise yesterday have voted -1 to [VOTE] James 2.3.0rc1 Release, as it's been two weeks that I said that I was going to test this weekend in my production system. And JAMES-515 is not a fix to a bug, simply a cleanup that could introduce problems to existing customers, and no perceived functional advantage. Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release plans
Ok, it's clear that we have (currently) a different view for 2.4. I think we should wait for 2.3.0 final and then maybe we should vote about the roadmap and procedures for 2.4.0/3.0. My idea on this topic could be influenced anyway by the final release date for 2.3.0 so it does not make sense to start a long discussion on this issue now. Stefano Noel J. Bergman wrote: We can backport here *anything* from trunk if we keep storage compatibility and mailet api compatibility. Yes, we CAN, but I don't know that we WANT to. I listed a few relatively low-risk, high-value items to make the difference between v2.3 and v2.4. I am not willing to say *anything* without agreeing on what each thing would be. v2.4 should NOT be a major development, but only low-risk, high-value additions to v2.3 while we focus on v3 (trunk). Currently IIRC anything we have in trunk could be part of the 2.4 release as we didn't introduce any incompatibility. But did we introduce any benefit? List the changes that you want to handle, and we can talk about it. FetchMail, for example, I would say no. Why not? Because my recollection is that there is no benefit to the new code other than it being a bit cleaner in your view (not making a personal judgment of my own). And, as we have all seen during the v2.3 beta phase, even the most innocent of changes can create defects. So I maintain the v2.4 concept: low-risk, high-value - no value, no change. If we want to follow this roadmap I would avoid to commit anything 3.0 specific in trunk until we have a 2.3.0 final out. Then I would start a 2.4.0 branch from the trunk of that moment and from that point we would still have 2 active tree (2.4 branch and trunk for 3.0). I would not. Instead, I would rename the v2.3 branch to v2.4, after creating the v2.3 tag. I would have no intention of maintaining v2.3.x separately. v2.4 would be the maintanence for v2.3. And trunk would be the next major release. However, if someone wants to enumerate the code changes between v2.3 and trunk, and make a case for each one, I'm willing for us all to risk assess them. And if the final view is that using trunk for v2.4 is correct, then that's what we'll do. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release plans
Am Sonntag, den 23.07.2006, 00:22 +0200 schrieb Stefano Bagnara: Ok, it's clear that we have (currently) a different view for 2.4. I think we should wait for 2.3.0 final and then maybe we should vote about the roadmap and procedures for 2.4.0/3.0. My idea on this topic could be influenced anyway by the final release date for 2.3.0 so it does not make sense to start a long discussion on this issue now. Yes.. Let us push 2.3.0 final before make to much discusses.. I have also some stuff in queue which could be in 2.4 .. but let us talk about that later ;-) bye Norman Stefano Noel J. Bergman wrote: We can backport here *anything* from trunk if we keep storage compatibility and mailet api compatibility. Yes, we CAN, but I don't know that we WANT to. I listed a few relatively low-risk, high-value items to make the difference between v2.3 and v2.4. I am not willing to say *anything* without agreeing on what each thing would be. v2.4 should NOT be a major development, but only low-risk, high-value additions to v2.3 while we focus on v3 (trunk). Currently IIRC anything we have in trunk could be part of the 2.4 release as we didn't introduce any incompatibility. But did we introduce any benefit? List the changes that you want to handle, and we can talk about it. FetchMail, for example, I would say no. Why not? Because my recollection is that there is no benefit to the new code other than it being a bit cleaner in your view (not making a personal judgment of my own). And, as we have all seen during the v2.3 beta phase, even the most innocent of changes can create defects. So I maintain the v2.4 concept: low-risk, high-value - no value, no change. If we want to follow this roadmap I would avoid to commit anything 3.0 specific in trunk until we have a 2.3.0 final out. Then I would start a 2.4.0 branch from the trunk of that moment and from that point we would still have 2 active tree (2.4 branch and trunk for 3.0). I would not. Instead, I would rename the v2.3 branch to v2.4, after creating the v2.3 tag. I would have no intention of maintaining v2.3.x separately. v2.4 would be the maintanence for v2.3. And trunk would be the next major release. However, if someone wants to enumerate the code changes between v2.3 and trunk, and make a case for each one, I'm willing for us all to risk assess them. And if the final view is that using trunk for v2.4 is correct, then that's what we'll do. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] !EXCUBATOR:1,44c2a56243381943058642! signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
RE: Release plans
Norman Maurer wrote: Noel J. Bergman wrote: Stefano wrote: If we want to follow this roadmap I would avoid to commit anything 3.0 specific in trunk until we have a 2.3.0 final out. Then I would start a 2.4.0 branch from the trunk of that moment and from that point we would still have 2 active tree (2.4 branch and trunk for 3.0). I would not. Instead, I would rename the v2.3 branch to v2.4, after creating the v2.3 tag. I would have no intention of maintaining v2.3.x separately. v2.4 would be the maintanence for v2.3. And trunk would be the next major release. I whould try to get the 2.3 final first and close the 2.3 branch after that. Final first, yes. But there is no need to maintain the branch after we are done with it. We run `svn cp branches/v2.3 tags/RELEASE_2_3`, which gives us a copy, then run `svn mv branches/v2.3 branches/v2.4` and we have renamed the branch. If, for some reason, we ever needed a branches/v2.3, we can copy the tag. Remember: Subversion is not CVS. We have different, better, ways to do things. Then we should copy the 2.3 to 2.4 and [decide] what we want to have in 2.4 and copy the stuff from trunk. We're differing only in SVN mechanics, as described above. I think we could put and should put more then fastfail and launcher in 2.4. Maybe support fastfail also in RemoteManager and Pop3 server ? What do you mean? And why? Has anyone ever reported problems that suggest that we need fast-fail in either of those two? I don't know if those would survive the high-value test. But what about all of the admin work that Bernd has been doing? Again, my suggestion is that v2.4 be focused on the low-risk, high-value equation. This is a plan to focus development on v3, while providing a means to put only the most valuable, compatible, and lower risk improvements into a v2.4 release. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release plans
Hi, So let me add some comments.. Am Samstag, den 22.07.2006, 18:56 -0400 schrieb Noel J. Bergman: Norman Maurer wrote: Noel J. Bergman wrote: Stefano wrote: If we want to follow this roadmap I would avoid to commit anything 3.0 specific in trunk until we have a 2.3.0 final out. Then I would start a 2.4.0 branch from the trunk of that moment and from that point we would still have 2 active tree (2.4 branch and trunk for 3.0). I would not. Instead, I would rename the v2.3 branch to v2.4, after creating the v2.3 tag. I would have no intention of maintaining v2.3.x separately. v2.4 would be the maintanence for v2.3. And trunk would be the next major release. I whould try to get the 2.3 final first and close the 2.3 branch after that. Final first, yes. But there is no need to maintain the branch after we are done with it. We run `svn cp branches/v2.3 tags/RELEASE_2_3`, which gives us a copy, then run `svn mv branches/v2.3 branches/v2.4` and we have renamed the branch. If, for some reason, we ever needed a branches/v2.3, we can copy the tag. Ok i think we think about the same ;-) Remember: Subversion is not CVS. We have different, better, ways to do things. Then we should copy the 2.3 to 2.4 and [decide] what we want to have in 2.4 and copy the stuff from trunk. We're differing only in SVN mechanics, as described above. See above .. I think we could put and should put more then fastfail and launcher in 2.4. Maybe support fastfail also in RemoteManager and Pop3 server ? What do you mean? And why? Has anyone ever reported problems that suggest that we need fast-fail in either of those two? I don't know if those would survive the high-value test. The advance of that whould be to allow easy integration of costum handlers and fitlers.. It was just a thought which raise on a talk to Stefano.. And the benefit of that whould maybe to share technic we use for handlers.. But what about all of the admin work that Bernd has been doing? I not test it yet .. but yes the spooling commands etc could easy integrate to 2.4. Like i said with the jmx i have no expirence. But im not -1 if the others want to include it. Again, my suggestion is that v2.4 be focused on the low-risk, high-value equation. This is a plan to focus development on v3, while providing a means to put only the most valuable, compatible, and lower risk improvements into a v2.4 release. Yes.. i agree but i think a 2.4 only should released if we can put some more new code to it.. I will commit my pop before smtp stuff to trunk the next day ( maybe days) this could also be a good feature for 2.4.. But plz let us release 2.3.0 final first before get to much in details about that. I think that should be the highest prio we should focus on --- Noel bye Norman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
sendpartial is false?
Anyone know why this is still defaulting to false instead of true? I use true in my own config.xml. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
