Re: Resolved: (JAMES-413) James does not resolve CNAME DNS registrations
FYI, I compared our codes and while functionally equivalent, I must admit that your fix was cleaner and simpler ;-( So let us stick to that. --Søren On Wednesday 07 September 2005 09:25, Stefano Bagnara wrote: You move fast Stefano! I was about to commit my fix for it, when I ran into the SpoolManager issues. I will compare our fixes :-) Feel free to overwrite my changes with yours! Mine has been a really fast fix. I will run my test against your code, eventually! Stefano PS: sorry, I've seen you have the bug assigned but I was not sure you were working on it so I gave it a try. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer at tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [dev-crypto] warning about JavaMail 1.3.3
Just saw this on the BouncyCastle mailinglist, as we provide mailets using BouncyCastle we should perhaps revise upgrading to JavaMail 1.3.3. --Søren -- Forwarded Message -- Subject: [dev-crypto] warning about JavaMail 1.3.3 Date: Thursday 08 September 2005 00:25 From: David Hook [EMAIL PROTECTED] To: [EMAIL PROTECTED] We're not sure exactly what's happening still, but it appears that on some platforms, under some circumstances, Base64 decoding, or something underlying it, in JavaMail 1.3.3 breaks horribly and produces data with lots of extra bytes of the value 0x00 and 0xff. The upshot of this is that messages containing Base64 encoded data, such as S/MIME messages will no longer work as the data stream containing the encoded message has become corrupted. If S/MIME starts causing exceptions we recommend moving back to 1.3.2. Regards, David --- -- Søren Hilmer, M.Sc. RD manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer at tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switch to Loom 1.0RC3
Good! Attach some dates and we have a release plan! Since there was talk about feature freeze, I thought we were somewhere before the release cycle. I didn't really follow the alpha series for 2.2.0, so I wasn't aware that there will be a bunch of them. The alpha phase can be shortened if there are less features still being put in. I think it is important to have a first alpha release soon, along with a plan of what's still going in and when. As for Loom, I am curious about the white space issue -- whether it can be fixed before the James release. There might be other 'little' issues like this that may turn out to be nasty. So it should be thoroughly tested. Would it be an idea to release James with both Phoenix (not perfect but well known) and Loom (better but more unknown), with Phoenix the default? Cheers, Hes. Stefano Bagnara wrote: I thought the 2.3.0 release was coming up shortly? You mean that it is the right time to put Loom in, just before releasing the RCs for 2.3.0. Is it correct that your point is that real testing will be done with the RCs, not with the trunk? Cheers, Let me explain what is the release cycle in my head: Alpha cycle: - add new features - handle bug reports - test it is working and release an alpha - fix bugs or delay them to a following alpha/beta - schedule feature/bug fixes for the releases Repeat Alpha cycle until your major features are in. Beta cycle - handle bug reports - fix bugs or delay them to a following beta - test and release a new beta - schedule bug fixes for the next release Repeat Beta cycles until your minor features are completed and you have fixed all the bugs you want to fix RC cycle - release a candidate - wait for show-stoppers - fix show-stoppers Repeat RC cycles until you have showstoppers. Final release Currently we are in the first step of the Alpha Cycle, you can see that this is the most distant point from the final release in the release cycle. Note that the cycles are not binded to real/solar time: the whole process can take years or weeks depending on too many factors. What I would like is to do a fist alpha release as soon as possible so we start understanding what the roadmap for following Alphas and Betas will be. We can only plan alphas/betas. Isn't this the common way to operate? 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: Switch to Loom 1.0RC3
I'm not sure I would like to use phoenix-trunk: does any other project use it? Does anyone use LOOM? From what Peter Royal told me, I understood that development on LOOM is dead. And we don't have access to the code. I'd like to hear from Peter regarding Loom vs Phoenix, but he seemed willing to help us update the container. Well, LOOM had a release cycle in the last year and we have access to sourcecode, buglist, feature, documentation, and an 1.0RC3 distribution For Phoenix we have a repository trunk that does not run james, no feature list, no documentation and no official distribution. I Just tested the 2 distributions Peter sent to me today. One runs under the same conditions of Loom (needed to change the data-sources configuration), the other one (the one he's using) does not find a package that I've not been able to find anywhere (java.lang.NoClassDefFoundError: org/apache/avalon/excalibur/packagemanager/impl/DefaultExtensionManager). And I never proposed that we precipitously dump the Avalon interfaces. I am suggested that we not add MORE dependencies, and start to incrementally drop the one's we have. I already explained this: IMHO the change removed avalon specific source code in favor of avalon specific configuration. BTW this is an useless discussion: we can deploy our dbcp class by removing/changing the schema.xml file from the just released cornerstone-datasources-impl-2.1.jar. This exact problem does exists with both Phoenix-LatestFromPeterRoyal and Loom-1.0RC3 (1). Now that I looked to it better phoenix-trunk didn't work for the same exact issues Loom didn't: simply Loom gave me better error and I found the problems and fixed them. Now our codebase is compatible with phoenix-trunk, phoenix-4.0.4 and loom-1.0RC3. Our config.xml is not valid but the important thing is that the code is compliant. Both phoenix-trunk and loom-1.0RC3 should correctly handle the classpath for the contained application (they add any jar in SAR-INF/lib to the classpath). Stefano (1) Just look at this file: lib\cornerstone-datasources-impl-2.1.jar\org\apache\avalon\cornerstone\block s\datasources\DefaultDataSourceSelector-schema.xml It validates the data-souces element only when its class attribute contain the org.apache.avalon.excalibur.datasource.JdbcDataSource line. element name=data-source attribute name=name/ attribute name=classvalueorg.apache.avalon.excalibur.datasource.JdbcDataSource/v alue/attribute - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switch to Loom 1.0RC3
(my idea was a little different but I saw the first reaction and I changed my mind). But no commiter gave a -1 till yet. Why shouldn't we switch if it works for you? Did anyone proved the contrary or had any founded with tests argument - except FUD? After that we could still investigate that 'space problem'. You are waiting for minimum 3 + votes? But are there so many active comitters on this list? If yes, than make another thread, called [vote] and count only the arguments of commiters. IMHO the container is not part of our application (James) and james should run fine in each container using the pros and cons of each container. AFAIK this was planned for 3.0 with that POJO strategy :). People that need functional classloaders will need to use loom. People that need to do hot deploy/undeploy of applications will use loom. But will the users be able to switch to loom? I suspect not. Wouldn't be better to switch officially for the coming alphas so that everybody can test it? Thanks in advance, Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switch to Loom 1.0RC3
Good! Attach some dates and we have a release plan! Right, but we are not a company and we advance with sparetime so we can simply decide the order of steps in the cycle and not dates. [...] The alpha phase can be shortened if there are less features still being put in. I think it is important to have a first alpha release soon, along with a plan of what's still going in and when. All of us agreed on this. We'll have an alpha release soon. As for Loom, I am curious about the white space issue -- whether it can be fixed before the James release. There might be other 'little' issues like this that may turn out to be nasty. So it should be thoroughly tested. I think that the container issue is MINOR and somewhat unrelated to the release. When you release a war application you declare the servlet containers that are able to run it but you don't bind your application to a specific container. I simply think that we should not add workarounds in our code to avoid bugs in the phoenix version we are currently distributing with james. I would prefer to bundle a newer container. And about phoenix being well-known: can you provide links of software currently using an unreleased phoenix release (either 4.0.4 we currently bundle or the trunk)? Would it be an idea to release James with both Phoenix (not perfect but well known) and Loom (better but more unknown), with Phoenix the default? I personally don't like this option: people would start asking why we bundle 2 container, what are the differences and we don't have good answers. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switch to Loom 1.0RC3
Does anyone use LOOM? If it does the job we need, why shouln't we use it till the 'great POJO-fication' that might(or not) come in the far future. From what Peter Royal told me, I understood that development on LOOM is dead. Judging from the source code, if LOOM is dead than Avalon could be called 'rotten' :). I am suggested that we not add MORE dependencies, and start to incrementally drop the one's we have. As I understood, using LOOM doesn't add MORE dependencies, cause it's replacement is simple. So if there will be a better alternative, to drop it will be an equal work as to drop Avalon. Thanks in advance, Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switch to Loom 1.0RC3
(my idea was a little different but I saw the first reaction and I changed my mind). But no commiter gave a -1 till yet. Why shouldn't we switch if it works for you? I didn't run a vote ;-) Did anyone proved the contrary or had any founded with tests argument - except FUD? IMHO we still have the problem with spaces in the config.xml: this is a real problem. Probably phoenix-trunk is the solution but I'm not sure it's stable and I don't know what the features of phoenix-trunk are: probably I should build the phoenix-trunk website from trunk to find more informations. After that we could still investigate that 'space problem'. You are waiting for minimum 3 + votes? But are there so many active comitters on this list? If yes, than make another thread, called [vote] and count only the arguments of commiters. No. I started a discussion thread and not a vote thread because I, in first place, want to discuss differences between containers. I want to know the personal considerations of other committers about this kind of changes as I had time to test different containers and I wanted to report back my first impressions. IMHO the container is not part of our application (James) and james should run fine in each container using the pros and cons of each container. AFAIK this was planned for 3.0 with that POJO strategy :). Sorry, I was referring to Avalon containers. Loom, Metro, Merlin, Phoenix, Fortress are all Avalon containers. James should run fine in all of them. People that need functional classloaders will need to use loom. People that need to do hot deploy/undeploy of applications will use loom. But will the users be able to switch to loom? I suspect not. You will just need to download loom, place your james.sar (latest trunk will create a james.sar compatible with loom/phoenix-trunk) in its apps folder and remove spaces in your config.xml. Just execute run.bat or run.sh and it works. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switch to Loom 1.0RC3
IMHO we still have the problem with spaces in the config.xml: this is a real problem. But isn't there any simple solution to this 'space problem'? I always thought(me naive) that such issues are just a matter of parser configuration, cause we talk about XML here :). Probably phoenix-trunk is the solution but I'm not sure it's stable and I don't know what the features of phoenix-trunk are: probably I should build the phoenix-trunk website from trunk to find more informations. Wouldn't take far less time to investigate the 'space problem' instead? Considering that you have at least the fact that LOOM WAS working for you, except that space? I think this is a big argument. You will just need to download loom, place your james.sar (latest trunk will create a james.sar compatible with loom/phoenix-trunk) in its apps folder and remove spaces in your config.xml. Just execute run.bat or run.sh and it works. This seems OK, but I still think that if LOOM is good, it should be used by default, and those with FUD should just investigate/test, and bring proofs, not just FUD, period :). Thanks in advance, Ahmed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switch to Loom 1.0RC3
IMHO we still have the problem with spaces in the config.xml: this is a real problem. But isn't there any simple solution to this 'space problem'? I always thought(me naive) that such issues are just a matter of parser configuration, cause we talk about XML here :). Yes and no. Avalon containers provide their own Confiuguration objects to the contained application. This means that the config.xml is a container file and not an application file and IS container specific. We include a phoenix specific config.xml that works fine when read by phoenix NamespacedSAXConfigurationParser. Loom use the same name config.xml and the same notation to configure the applications but use it's own jar to handle the parsing. This is not configurable and we would have to change the loom source code to alter it. Probably phoenix-trunk is the solution but I'm not sure it's stable and I don't know what the features of phoenix-trunk are: probably I should build the phoenix-trunk website from trunk to find more informations. Wouldn't take far less time to investigate the 'space problem' instead? Considering that you have at least the fact that LOOM WAS working for you, except that space? I think this is a big argument. phoenix-trunk is also working for me now that Loom helped me fixing james.sar incompatibilities. And we don't want to distribute an application that works for me: we want to distribute an application that just works for most people. You will just need to download loom, place your james.sar (latest trunk will create a james.sar compatible with loom/phoenix-trunk) in its apps folder and remove spaces in your config.xml. Just execute run.bat or run.sh and it works. This seems OK, but I still think that if LOOM is good, it should be used by default, and those with FUD should just investigate/test, and bring proofs, not just FUD, period :). I don't know if LOOM is better than phoenix-trunk. I started this discussion with a question should we move to loom? and I haven't made a proposal because I need a more clear scenario to make any proposal around this issue. I just currently think that the space issue is blocking. I don't understand why most of the replies have been around the data-source issue and the fact the loom is dead that IMHO are non-existing issues, but the whole thread is helping me. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-crypto] warning about JavaMail 1.3.3
Just saw this on the BouncyCastle mailinglist, as we provide mailets using BouncyCastle we should perhaps revise upgrading to JavaMail 1.3.3. --Søren Hi Søren, Thank you for pointing this out. What should we do? I haven't tested S/MIME stuff since the upgrade to javamail 1.3.3. Should I revert the upgrade to mail-1.3.3? Should we add a FAQ? Should we add a note in the config.xml just before the SMIME stuff? Stefano Subject: [dev-crypto] warning about JavaMail 1.3.3 Date: Thursday 08 September 2005 00:25 From: David Hook [EMAIL PROTECTED] To: [EMAIL PROTECTED] We're not sure exactly what's happening still, but it appears that on some platforms, under some circumstances, Base64 decoding, or something underlying it, in JavaMail 1.3.3 breaks horribly and produces data with lots of extra bytes of the value 0x00 and 0xff. The upshot of this is that messages containing Base64 encoded data, such as S/MIME messages will no longer work as the data stream containing the encoded message has become corrupted. If S/MIME starts causing exceptions we recommend moving back to 1.3.2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-crypto] warning about JavaMail 1.3.3
Well good questions, I read your entry on the upgrade, wher you state: Probably only performance improvement on base64 encoding/decoding. Most of the other changes are around IMAP (client) and we don't use it. So our main reason is the performance improvement in base64 handling, and this is exactly what seams broken. So I suggest reverting to JavaMail 1.3.2 until a bugfix-release from Sun is available. --Søren On Thursday 08 September 2005 11:25, Stefano Bagnara wrote: Just saw this on the BouncyCastle mailinglist, as we provide mailets using BouncyCastle we should perhaps revise upgrading to JavaMail 1.3.3. --Søren Hi Søren, Thank you for pointing this out. What should we do? I haven't tested S/MIME stuff since the upgrade to javamail 1.3.3. Should I revert the upgrade to mail-1.3.3? Should we add a FAQ? Should we add a note in the config.xml just before the SMIME stuff? Stefano Subject: [dev-crypto] warning about JavaMail 1.3.3 Date: Thursday 08 September 2005 00:25 From: David Hook [EMAIL PROTECTED] To: [EMAIL PROTECTED] We're not sure exactly what's happening still, but it appears that on some platforms, under some circumstances, Base64 decoding, or something underlying it, in JavaMail 1.3.3 breaks horribly and produces data with lots of extra bytes of the value 0x00 and 0xff. The upshot of this is that messages containing Base64 encoded data, such as S/MIME messages will no longer work as the data stream containing the encoded message has become corrupted. If S/MIME starts causing exceptions we recommend moving back to 1.3.2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer at tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (JAMES-416) Upgrade to javamail-1.3.3
[ http://issues.apache.org/jira/browse/JAMES-416?page=all ] Stefano Bagnara reopened JAMES-416: --- I'm reopening this because we should downgrade to 1.3.2 before an official release. -- Well good questions, I read your entry on the upgrade, wher you state: Probably only performance improvement on base64 encoding/decoding. Most of the other changes are around IMAP (client) and we don't use it. So our main reason is the performance improvement in base64 handling, and this is exactly what seams broken. So I suggest reverting to JavaMail 1.3.2 until a bugfix-release from Sun is available. --Søren On Thursday 08 September 2005 11:25, Stefano Bagnara wrote: Just saw this on the BouncyCastle mailinglist, as we provide mailets using BouncyCastle we should perhaps revise upgrading to JavaMail 1.3.3. --Søren Hi Søren, Thank you for pointing this out. What should we do? I haven't tested S/MIME stuff since the upgrade to javamail 1.3.3. Should I revert the upgrade to mail-1.3.3? Should we add a FAQ? Should we add a note in the config.xml just before the SMIME stuff? Stefano Subject: [dev-crypto] warning about JavaMail 1.3.3 Date: Thursday 08 September 2005 00:25 From: David Hook [EMAIL PROTECTED] To: [EMAIL PROTECTED] We're not sure exactly what's happening still, but it appears that on some platforms, under some circumstances, Base64 decoding, or something underlying it, in JavaMail 1.3.3 breaks horribly and produces data with lots of extra bytes of the value 0x00 and 0xff. The upshot of this is that messages containing Base64 encoded data, such as S/MIME messages will no longer work as the data stream containing the encoded message has become corrupted. If S/MIME starts causing exceptions we recommend moving back to 1.3.2. Upgrade to javamail-1.3.3 - Key: JAMES-416 URL: http://issues.apache.org/jira/browse/JAMES-416 Project: James Type: Task Versions: 2.3.0 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Priority: Minor Fix For: 2.3.0 Probably only performance improvement on base64 encoding/decoding. Most of the other changes are around IMAP (client) and we don't use it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-337) Exception when FromRepository tries to delete a message
[
http://issues.apache.org/jira/browse/JAMES-337?page=comments#action_12322924 ]
Stefano Bagnara commented on JAMES-337:
---
Can we mark this as closed?
Exception when FromRepository tries to delete a message
---
Key: JAMES-337
URL: http://issues.apache.org/jira/browse/JAMES-337
Project: James
Type: Bug
Components: MailStore MailRepository
Versions: 2.2.0
Reporter: Hes Siemelink
I am trying to get a FromRepository in the air, that will respool messages
that were dumped in an error repository earlier.
This is my configuration:
!-- Respool messages that could not be delivered earlier --
mailet match=SubjectStartsWith=Respool-Out class=FromRepository
repositoryPath file://../../../../spool/outgoing-undeliverable/
/repositoryPath
processor root /processor
delete true /delete
/mailet
However, when this mailet is triggered I get the following exception.
java.lang.ClassCastException
at
org.apache.james.mailrepository.AvalonMailRepository.remove(AvalonMailRepository.java:372)
at
org.apache.james.transport.mailets.FromRepository.service(FromRepository.java:132)
at
org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:407)
at
org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:451)
at
org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:360)
at java.lang.Thread.run(Unknown Source)
Messages seem to be respooled but are not deleted.
Proposed fix: Make AvalonMailRepository.remove(Collection) take Collections
of Strings as well as Collections of MailImpl objects.
Proposed new implementation:
/**
* Removes a Collection of mails from the repository
* @param mails The Collection of codeMailImpl/code's to delete
* @throws MessagingException
* @since 2.2.0
*/
public void remove(Collection mails) throws MessagingException {
Iterator delList = mails.iterator();
while (delList.hasNext()) {
Object next = delList.next();
if (next instanceof MailImpl) {
remove( (MailImpl) next);
}
else if (next instanceof String) {
remove( (String) next);
}
else if (next instanceof Collection) {
remove( (Collection) next);
}
}
}
Diff against 2.2.0 release tag:
Index: AvalonMailRepository.java
===
--- AvalonMailRepository.java (revision 37982)
+++ AvalonMailRepository.java (working copy)
@@ -369,7 +369,16 @@
public void remove(Collection mails) throws MessagingException {
Iterator delList = mails.iterator();
while (delList.hasNext()) {
-remove((MailImpl)delList.next());
+Object next = delList.next();
+if (next instanceof MailImpl) {
+remove( (MailImpl) next);
+}
+else if (next instanceof String) {
+remove( (String) next);
+}
+else if (next instanceof Collection) {
+remove( (Collection) next);
+}
}
}
@@ -404,7 +413,7 @@
*
*/
public Iterator list() {
-// Fix ConcurrentModificationException by cloning
+// Fix ConcurrentModificationException by cloning
// the keyset before getting an iterator
final ArrayList clone;
synchronized(keys) {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-317) FromProcessor doesn't delete, throws ClassCastException
[ http://issues.apache.org/jira/browse/JAMES-317?page=comments#action_12322925 ] Stefano Bagnara commented on JAMES-317: --- Can we mark this as closed? FromProcessor doesn't delete, throws ClassCastException --- Key: JAMES-317 URL: http://issues.apache.org/jira/browse/JAMES-317 Project: James Type: Bug Components: Matchers/Mailets (bundled) Versions: 2.2.0 Reporter: Noel J. Bergman Fix For: 2.3.0 FromRepository doesn't delete messages. Using delete results in a ClassCastException: java.lang.ClassCastException at AvalonMailRepository.java:372 at FromRepository.java:132 The code is calling MailRepository.remove(Collection) which expects a CollectionMail, but is being passed a CollectionString. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-337) Exception when FromRepository tries to delete a message
[
http://issues.apache.org/jira/browse/JAMES-337?page=comments#action_12322932 ]
Hes Siemelink commented on JAMES-337:
-
By all means!
Exception when FromRepository tries to delete a message
---
Key: JAMES-337
URL: http://issues.apache.org/jira/browse/JAMES-337
Project: James
Type: Bug
Components: MailStore MailRepository
Versions: 2.2.0
Reporter: Hes Siemelink
I am trying to get a FromRepository in the air, that will respool messages
that were dumped in an error repository earlier.
This is my configuration:
!-- Respool messages that could not be delivered earlier --
mailet match=SubjectStartsWith=Respool-Out class=FromRepository
repositoryPath file://../../../../spool/outgoing-undeliverable/
/repositoryPath
processor root /processor
delete true /delete
/mailet
However, when this mailet is triggered I get the following exception.
java.lang.ClassCastException
at
org.apache.james.mailrepository.AvalonMailRepository.remove(AvalonMailRepository.java:372)
at
org.apache.james.transport.mailets.FromRepository.service(FromRepository.java:132)
at
org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:407)
at
org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:451)
at
org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:360)
at java.lang.Thread.run(Unknown Source)
Messages seem to be respooled but are not deleted.
Proposed fix: Make AvalonMailRepository.remove(Collection) take Collections
of Strings as well as Collections of MailImpl objects.
Proposed new implementation:
/**
* Removes a Collection of mails from the repository
* @param mails The Collection of codeMailImpl/code's to delete
* @throws MessagingException
* @since 2.2.0
*/
public void remove(Collection mails) throws MessagingException {
Iterator delList = mails.iterator();
while (delList.hasNext()) {
Object next = delList.next();
if (next instanceof MailImpl) {
remove( (MailImpl) next);
}
else if (next instanceof String) {
remove( (String) next);
}
else if (next instanceof Collection) {
remove( (Collection) next);
}
}
}
Diff against 2.2.0 release tag:
Index: AvalonMailRepository.java
===
--- AvalonMailRepository.java (revision 37982)
+++ AvalonMailRepository.java (working copy)
@@ -369,7 +369,16 @@
public void remove(Collection mails) throws MessagingException {
Iterator delList = mails.iterator();
while (delList.hasNext()) {
-remove((MailImpl)delList.next());
+Object next = delList.next();
+if (next instanceof MailImpl) {
+remove( (MailImpl) next);
+}
+else if (next instanceof String) {
+remove( (String) next);
+}
+else if (next instanceof Collection) {
+remove( (Collection) next);
+}
}
}
@@ -404,7 +413,7 @@
*
*/
public Iterator list() {
-// Fix ConcurrentModificationException by cloning
+// Fix ConcurrentModificationException by cloning
// the keyset before getting an iterator
final ArrayList clone;
synchronized(keys) {
--
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-337) Exception when FromRepository tries to delete a message
[ http://issues.apache.org/jira/browse/JAMES-337?page=all ]
Stefano Bagnara resolved JAMES-337:
---
Fix Version: 2.3.0
Resolution: Duplicate
Assign To: Noel J. Bergman
Noel fix to JAMES-317 invalidate this.
Exception when FromRepository tries to delete a message
---
Key: JAMES-337
URL: http://issues.apache.org/jira/browse/JAMES-337
Project: James
Type: Bug
Components: MailStore MailRepository
Versions: 2.2.0
Reporter: Hes Siemelink
Assignee: Noel J. Bergman
Fix For: 2.3.0
I am trying to get a FromRepository in the air, that will respool messages
that were dumped in an error repository earlier.
This is my configuration:
!-- Respool messages that could not be delivered earlier --
mailet match=SubjectStartsWith=Respool-Out class=FromRepository
repositoryPath file://../../../../spool/outgoing-undeliverable/
/repositoryPath
processor root /processor
delete true /delete
/mailet
However, when this mailet is triggered I get the following exception.
java.lang.ClassCastException
at
org.apache.james.mailrepository.AvalonMailRepository.remove(AvalonMailRepository.java:372)
at
org.apache.james.transport.mailets.FromRepository.service(FromRepository.java:132)
at
org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:407)
at
org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:451)
at
org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:360)
at java.lang.Thread.run(Unknown Source)
Messages seem to be respooled but are not deleted.
Proposed fix: Make AvalonMailRepository.remove(Collection) take Collections
of Strings as well as Collections of MailImpl objects.
Proposed new implementation:
/**
* Removes a Collection of mails from the repository
* @param mails The Collection of codeMailImpl/code's to delete
* @throws MessagingException
* @since 2.2.0
*/
public void remove(Collection mails) throws MessagingException {
Iterator delList = mails.iterator();
while (delList.hasNext()) {
Object next = delList.next();
if (next instanceof MailImpl) {
remove( (MailImpl) next);
}
else if (next instanceof String) {
remove( (String) next);
}
else if (next instanceof Collection) {
remove( (Collection) next);
}
}
}
Diff against 2.2.0 release tag:
Index: AvalonMailRepository.java
===
--- AvalonMailRepository.java (revision 37982)
+++ AvalonMailRepository.java (working copy)
@@ -369,7 +369,16 @@
public void remove(Collection mails) throws MessagingException {
Iterator delList = mails.iterator();
while (delList.hasNext()) {
-remove((MailImpl)delList.next());
+Object next = delList.next();
+if (next instanceof MailImpl) {
+remove( (MailImpl) next);
+}
+else if (next instanceof String) {
+remove( (String) next);
+}
+else if (next instanceof Collection) {
+remove( (Collection) next);
+}
}
}
@@ -404,7 +413,7 @@
*
*/
public Iterator list() {
-// Fix ConcurrentModificationException by cloning
+// Fix ConcurrentModificationException by cloning
// the keyset before getting an iterator
final ArrayList clone;
synchronized(keys) {
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-328) TOP msg 0 does not return a terminator on error
[ http://issues.apache.org/jira/browse/JAMES-328?page=comments#action_12322961 ] Stefano Bagnara commented on JAMES-328: --- Here is the exception that is thrown: java.io.IOException: Unknown encoding: plain at javax.mail.internet.MimePartDataSource.getInputStream(MimePartDataSource.java:82) at javax.activation.DataHandler.getInputStream(DataHandler.java:220) at javax.mail.internet.MimeMessage.getInputStream(MimeMessage.java:1242) at org.apache.james.core.MimeMessageWrapper.getInputStream(MimeMessageWrapper.java:652) at org.apache.james.core.MailImpl.writeContentTo(MailImpl.java:500) at org.apache.james.pop3server.POP3Handler.doTOP(POP3Handler.java:976) at org.apache.james.pop3server.POP3Handler.parseCommand(POP3Handler.java:491) at org.apache.james.pop3server.POP3Handler.handleConnection(POP3Handler.java:273) at org.apache.james.util.connection.ServerConnection$ClientConnectionRunner.run(ServerConnection.java:410) at org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:55) at org.apache.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:116) do we really need to parse the message to get it as inputstream when we are reading it from a streamrepository??? Maybe we have to convert 8bit messages to 7bit? TOP msg 0 does not return a terminator on error - Key: JAMES-328 URL: http://issues.apache.org/jira/browse/JAMES-328 Project: James Type: Bug Components: POP3Server Versions: 2.2.0 Environment: James version 2.2.0 running on redhat 9, java version 1.4.2_03, mysql version 4.0.17 pc-linux-686 Reporter: John Glorioso Assignee: Stefano Bagnara Priority: Minor Fix For: 2.3.0 Attachments: top.diff I first noticed the problem using Java mail version 1.3.1 attempting to retrieve a malformed pop3 message from James. The message headers specify an invalid encoding type Content-Transfer-Encoding: plain. When the command TOP msg 0 is issued, James returns +OK Message follows, then successfully returns all headers. Upon attempting to retrieve 0 lines of the message, it apparently encounters an error with that invalid encoding type and returns -ERR Error while retrieving message. rather then the termination character of carriage return, period, carriage return. Javamail chokes on this waiting for the period termination character as it thinks that the -ERR text is a valid part of the message. The RETR command works properly however and returns the message without error. Looking into the source code for James, I found that even though the argument is to return 0 lines of the message, James still attempts to write the message to the output with the call mc.writeContentTo(nouts, lines); lines = 0 in this case and I put in a temporary work around to not do this unless lines was 0, but if a TOP command was issued with 5 for example, it would still return the invalid response. Not sure what the best solution is, but it needs to either return -ERR up front, or to return the termination character regardless so that dumb mail clients can process it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-421) MailImpls sharing MimeMessage's!
MailImpls sharing MimeMessage's! Key: JAMES-421 URL: http://issues.apache.org/jira/browse/JAMES-421 Project: James Type: Bug Components: James Core Versions: 2.3.0, 2.2.0 Reporter: Stefano Bagnara Assigned to: Stefano Bagnara Fix For: 2.3.0 LinearProcessor match a single recipient for a 2 recipient mail. it run MailImpl.duplicate. duplicate DOES NOT clone the MimeMessage. The following mailet will handle 2 different MailImpl sharing the same MimeMessage. Attached is the proving test. -- 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] Updated: (JAMES-421) MailImpls sharing MimeMessage's!
[ http://issues.apache.org/jira/browse/JAMES-421?page=all ] Stefano Bagnara updated JAMES-421: -- Attachment: LinearProcessorTest.java void setUp() create a new LinearProcessor in a mock environment. processor mailet match=[EMAIL PROTECTED] class=MyMailet /mailet mailet match=All class=MyMailet /mailet mailet match=All class=DumpSystemErr /mailet /processor Look at the output and you will see that it doesn't match what we expect. The test is not finished but looking at System.err you will understand the bug. MailImpls sharing MimeMessage's! Key: JAMES-421 URL: http://issues.apache.org/jira/browse/JAMES-421 Project: James Type: Bug Components: James Core Versions: 2.3.0, 2.2.0 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Fix For: 2.3.0 Attachments: LinearProcessorTest.java LinearProcessor match a single recipient for a 2 recipient mail. it run MailImpl.duplicate. duplicate DOES NOT clone the MimeMessage. The following mailet will handle 2 different MailImpl sharing the same MimeMessage. Attached is the proving test. -- 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] Updated: (JAMES-421) MailImpls sharing MimeMessage's!
[ http://issues.apache.org/jira/browse/JAMES-421?page=all ] Stefano Bagnara updated JAMES-421: -- Priority: Critical (was: Major) MailImpls sharing MimeMessage's! Key: JAMES-421 URL: http://issues.apache.org/jira/browse/JAMES-421 Project: James Type: Bug Components: James Core Versions: 2.3.0, 2.2.0 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Priority: Critical Fix For: 2.3.0 Attachments: LinearProcessorTest.java LinearProcessor match a single recipient for a 2 recipient mail. it run MailImpl.duplicate. duplicate DOES NOT clone the MimeMessage. The following mailet will handle 2 different MailImpl sharing the same MimeMessage. Attached is the proving test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-421) MailImpls sharing MimeMessage's!
[ http://issues.apache.org/jira/browse/JAMES-421?page=comments#action_12322983 ] Noel J. Bergman commented on JAMES-421: --- Mail objects are just addressing carriers for the message. They are not supposed to clone the message, since we may simply be effecting routing within the pipeline. The overhead would be huge if every split in routing caused a clone of the underlying message. MailImpls sharing MimeMessage's! Key: JAMES-421 URL: http://issues.apache.org/jira/browse/JAMES-421 Project: James Type: Bug Components: James Core Versions: 2.3.0, 2.2.0 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Priority: Critical Fix For: 2.3.0 Attachments: LinearProcessorTest.java LinearProcessor match a single recipient for a 2 recipient mail. it run MailImpl.duplicate. duplicate DOES NOT clone the MimeMessage. The following mailet will handle 2 different MailImpl sharing the same MimeMessage. Attached is the proving test. -- 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]
