[jira] [Created] (PROTOCOLS-36) NettyProtocolSession.writeResponse(...) does not maintain order of written Responses if FutureResponse and Response is mixed
NettyProtocolSession.writeResponse(...) does not maintain order of written Responses if FutureResponse and Response is mixed Key: PROTOCOLS-36 URL: https://issues.apache.org/jira/browse/PROTOCOLS-36 Project: JAMES Protocols Issue Type: Bug Affects Versions: 1.6 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 1.6 If we mix FutureResponse and Response implementation we MUST ensure that the right order of responses is maintained. This basicly means that we need to put responses in a queue and dequeue them in the right order (respecting the FutureResponse async nature) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (PROTOCOLS-31) Add a simple netty bases SMTPServer implementation
[ https://issues.apache.org/jira/browse/PROTOCOLS-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved PROTOCOLS-31. Resolution: Fixed done > Add a simple netty bases SMTPServer implementation > -- > > Key: PROTOCOLS-31 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-31 > Project: JAMES Protocols > Issue Type: New Feature > Components: smtp >Affects Versions: 1.5 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 1.6 > > > At the moment we only ship the api for the SMTP-Server + some transport > independent stuff. It would be nice if we could also include some simple > SMTPServer which can be used in an easy way. Something like subetha-smtp or > mailster. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (PROTOCOLS-26) Make AUTH method failed string a more useful error message
[
https://issues.apache.org/jira/browse/PROTOCOLS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Norman Maurer resolved PROTOCOLS-26.
Resolution: Fixed
Fix Version/s: (was: 1.5)
1.6
Committed. Sorry for the delay and thanks for the patch!
> Make AUTH method failed string a more useful error message
> --
>
> Key: PROTOCOLS-26
> URL: https://issues.apache.org/jira/browse/PROTOCOLS-26
> Project: JAMES Protocols
> Issue Type: Improvement
> Components: smtp
>Affects Versions: 1.5
>Reporter: Thomas UNG
>Assignee: Norman Maurer
>Priority: Minor
> Labels: patch
> Fix For: 1.6
>
> Attachments: AuthCmdHandler.java
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Have security sensitive information in log when auth login has failed
> - // TODO: Make this string a more useful error message
> - session.getLogger().error("AUTH method "+authType+" failed");
> + session.getLogger().error("AUTH method "+authType+" failed from " + user +
> "@" + session.getRemoteIPAddress());
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (PROTOCOLS-32) Add a lower-level api which allows Handlers to return a Response in a async fashion
[ https://issues.apache.org/jira/browse/PROTOCOLS-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved PROTOCOLS-32. Resolution: Fixed Fix Version/s: 1.6 > Add a lower-level api which allows Handlers to return a Response in a async > fashion > --- > > Key: PROTOCOLS-32 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-32 > Project: JAMES Protocols > Issue Type: New Feature > Components: api, smtp >Affects Versions: 1.5 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 1.6 > > > At the moment we let our handlers return the response. This may not the best > thing todo as sometimes we could benefit from doing this in a async manner. > We should add some api for that but still support the old (and simple) way -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (PROTOCOLS-34) LineHandler/ConnectHandler should return a Response
[ https://issues.apache.org/jira/browse/PROTOCOLS-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved PROTOCOLS-34. Resolution: Fixed Fix Version/s: 1.6 done... > LineHandler/ConnectHandler should return a Response > --- > > Key: PROTOCOLS-34 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-34 > Project: JAMES Protocols > Issue Type: Task >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 1.6 > > > LineHandler and ConectHandler should return a Response object if they want to > write a Msg back to the client and not use > ProtocolSession.writeResponse(...). This will make the contract much more > clear and also allows us to remove the writeResponse from it. this wilmguard > us from strange side effects in the future.. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (PROTOCOLS-35) Remove ProtocolSession.writeResponse(...)
Remove ProtocolSession.writeResponse(...) -- Key: PROTOCOLS-35 URL: https://issues.apache.org/jira/browse/PROTOCOLS-35 Project: JAMES Protocols Issue Type: Task Components: api Affects Versions: 1.5 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 1.6 We should remove ProtocolSession.writeResponse(...) method and just use on ProtocolTransport.write(...) if needed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (PROTOCOLS-34) LineHandler/ConnectHandler should return a Response
LineHandler/ConnectHandler should return a Response --- Key: PROTOCOLS-34 URL: https://issues.apache.org/jira/browse/PROTOCOLS-34 Project: JAMES Protocols Issue Type: Task Reporter: Norman Maurer Assignee: Norman Maurer LineHandler and ConectHandler should return a Response object if they want to write a Msg back to the client and not use ProtocolSession.writeResponse(...). This will make the contract much more clear and also allows us to remove the writeResponse from it. this wilmguard us from strange side effects in the future.. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1317) Mail spooled but not processed
[ https://issues.apache.org/jira/browse/JAMES-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112845#comment-13112845 ] Norman Maurer commented on JAMES-1317: -- Yes that should be right > Mail spooled but not processed > -- > > Key: JAMES-1317 > URL: https://issues.apache.org/jira/browse/JAMES-1317 > Project: JAMES Server > Issue Type: Bug > Components: SpoolManager & Processors >Affects Versions: 3.0-M1, 3.0-M2, 3.0-beta3 >Reporter: Raju Buchi >Priority: Critical > Fix For: 3.0-beta4 > > Attachments: jstack.zip > > > Mails sent to James server are spooled but they are not processed and sent > out. > The issue is similar to the one faced by Zach. > The server seems to be working fine for a few hours or few days, but some > time all the mails are spooled but they will not be processed and sent out. > Restarted the server several times and some time a few of the mails will be > processed and all the others are lost. > As Norman suggested I have took a jstack trace. > Please let me how we can resolve this issue > Thanks > - Raju -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1317) Mail spooled but not processed
[ https://issues.apache.org/jira/browse/JAMES-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1317. -- Resolution: Fixed Fix Version/s: 3.0-beta4 I think its fixed by JAMES-1319. Could you try with latest snapshots ? > Mail spooled but not processed > -- > > Key: JAMES-1317 > URL: https://issues.apache.org/jira/browse/JAMES-1317 > Project: JAMES Server > Issue Type: Bug > Components: SpoolManager & Processors >Affects Versions: 3.0-M1, 3.0-M2, 3.0-beta3 >Reporter: Raju Buchi >Priority: Critical > Fix For: 3.0-beta4 > > Attachments: jstack.zip > > > Mails sent to James server are spooled but they are not processed and sent > out. > The issue is similar to the one faced by Zach. > The server seems to be working fine for a few hours or few days, but some > time all the mails are spooled but they will not be processed and sent out. > Restarted the server several times and some time a few of the mails will be > processed and all the others are lost. > As Norman suggested I have took a jstack trace. > Please let me how we can resolve this issue > Thanks > - Raju -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1316) Add a file based MailQueue implementation
[ https://issues.apache.org/jira/browse/JAMES-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1316. -- Resolution: Fixed FileMailQueue is in trunk now > Add a file based MailQueue implementation > - > > Key: JAMES-1316 > URL: https://issues.apache.org/jira/browse/JAMES-1316 > Project: JAMES Server > Issue Type: New Feature > Components: Queue >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > We should "switch back" to a file based MailQueue implementation as default > as ActiveMQ just seems to be not stable enough for our needs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (PROTOCOLS-33) Encoder/Decoder should be generic
Encoder/Decoder should be generic - Key: PROTOCOLS-33 URL: https://issues.apache.org/jira/browse/PROTOCOLS-33 Project: JAMES Protocols Issue Type: Improvement Components: api Affects Versions: 1.5 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 1.6 For Netty we have an Encoder and Decoder to convert stuff to a Request and from a Response. This kind of Encoder / Decoder should not depend on netty and are generic as we also need it when using other transport implementations. The best thing would be to decode from byte[] to Response and encode from Request to byte[]. This will make it reusable with "any" transport impl. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (PROTOCOLS-32) Add a lower-level api which allows Handlers to return a Response in a async fashion
Add a lower-level api which allows Handlers to return a Response in a async fashion --- Key: PROTOCOLS-32 URL: https://issues.apache.org/jira/browse/PROTOCOLS-32 Project: JAMES Protocols Issue Type: New Feature Components: api, smtp Affects Versions: 1.5 Reporter: Norman Maurer Assignee: Norman Maurer At the moment we let our handlers return the response. This may not the best thing todo as sometimes we could benefit from doing this in a async manner. We should add some api for that but still support the old (and simple) way -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1302) SMTPNettySession.sleep(...) is not implemented
[ https://issues.apache.org/jira/browse/JAMES-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1302. -- Resolution: Invalid SMTPSession.sleep(..) was removed > SMTPNettySession.sleep(...) is not implemented > -- > > Key: JAMES-1302 > URL: https://issues.apache.org/jira/browse/JAMES-1302 > Project: JAMES Server > Issue Type: Bug > Components: SMTPServer >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Priority: Minor > Fix For: 3.0-beta4 > > > SMTPNettySession.sleep(..) is not implemented and so not usable. At the > moment it just do nothing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1303) IMAPServer / SMTPServer / POP3Server MAY close the Channel before all messages are flushed out
[ https://issues.apache.org/jira/browse/JAMES-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1303. -- Resolution: Fixed was done... > IMAPServer / SMTPServer / POP3Server MAY close the Channel before all > messages are flushed out > -- > > Key: JAMES-1303 > URL: https://issues.apache.org/jira/browse/JAMES-1303 > Project: JAMES Server > Issue Type: Bug > Components: IMAPServer, POP3Server, SMTPServer >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > At the moment we call Channel.close(); to close the channel. This will close > the channel without make sure that all currently queued message are flushed > out to the client. > This can lead to some strange side effects as we may not write all data for > the response out to the client before doing so. > See: > http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Flush-channel-before-close-td5634777.html > http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Netty-behavior-when-disconnecting-a-channel-td5861795.html#a5862024 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1320) MimeMessageWrapper.writeTo(...) calls saveChanges() even if not needed
[ https://issues.apache.org/jira/browse/JAMES-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1320. -- Resolution: Fixed done > MimeMessageWrapper.writeTo(...) calls saveChanges() even if not needed > -- > > Key: JAMES-1320 > URL: https://issues.apache.org/jira/browse/JAMES-1320 > Project: JAMES Server > Issue Type: Improvement >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > When MimeMessageWrapper.writeTo(...) is called we call saveChanges() > everytime even when the messagewas not modified at all. This is not neeed and > also can throw exceptions on malformated messages. > See the related stacktrace: > org.apache.james.queue.api.MailQueue$MailQueueException: Unable to enqueue > mail; > nested exception is: > javax.mail.internet.ParseException: Expected ';', got "windows-1250" > at > org.apache.james.queue.file.FileMailQueue.enQueue(FileMailQueue.java:193) > at > org.apache.james.queue.file.FileMailQueue.enQueue(FileMailQueue.java:230) > at > org.apache.james.smtpserver.SendMailHandler.onMessage(SendMailHandler.java:64) > at > org.apache.james.smtpserver.DataLineJamesMessageHookHandler.processExtensions(DataLineJamesMessageHookHandler.java:178) > at > org.apache.james.smtpserver.DataLineJamesMessageHookHandler.onLine(DataLineJamesMessageHookHandler.java:96) > at > org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:76) > at > org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:61) > at > org.apache.james.protocols.smtp.core.ReceivedDataLineFilter.onLine(ReceivedDataLineFilter.java:54) > at > org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:76) > at > org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:61) > at > org.apache.james.protocols.smtp.core.esmtp.MailSizeEsmtpExtension.onLine(MailSizeEsmtpExtension.java:147) > at > org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:76) > at > org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:61) > at > org.apache.james.protocols.impl.LineHandlerUpstreamHandler.messageReceived(LineHandlerUpstreamHandler.java:57) > at > org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80) > at > org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) > at > org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754) > at > org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:69) > at > org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecutor$ChildExecutor.run(OrderedMemoryAwareThreadPoolExecutor.java:316) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > Caused by: javax.mail.internet.ParseException: Expected ';', got > "windows-1250" > at javax.mail.internet.ParameterList.(ParameterList.java:289) > at javax.mail.internet.ContentType.(ContentType.java:114) > at > javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1322) > at > javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1021) > at > javax.mail.internet.MimeMultipart.updateHeaders(MimeMultipart.java:419) > at > javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1345) > at > javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1021) > at > javax.mail.internet.MimeMultipart.updateHeaders(MimeMultipart.java:419) > at > javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1345) > at > javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2106) > at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2074) > at > org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:295) > at > org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:290) > at > org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:286) > at > org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:271) >
[jira] [Created] (JAMES-1320) MimeMessageWrapper.writeTo(...) calls saveChanges() even if not needed
MimeMessageWrapper.writeTo(...) calls saveChanges() even if not needed -- Key: JAMES-1320 URL: https://issues.apache.org/jira/browse/JAMES-1320 Project: JAMES Server Issue Type: Improvement Affects Versions: 3.0-beta3 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 3.0-beta4 When MimeMessageWrapper.writeTo(...) is called we call saveChanges() everytime even when the messagewas not modified at all. This is not neeed and also can throw exceptions on malformated messages. See the related stacktrace: org.apache.james.queue.api.MailQueue$MailQueueException: Unable to enqueue mail; nested exception is: javax.mail.internet.ParseException: Expected ';', got "windows-1250" at org.apache.james.queue.file.FileMailQueue.enQueue(FileMailQueue.java:193) at org.apache.james.queue.file.FileMailQueue.enQueue(FileMailQueue.java:230) at org.apache.james.smtpserver.SendMailHandler.onMessage(SendMailHandler.java:64) at org.apache.james.smtpserver.DataLineJamesMessageHookHandler.processExtensions(DataLineJamesMessageHookHandler.java:178) at org.apache.james.smtpserver.DataLineJamesMessageHookHandler.onLine(DataLineJamesMessageHookHandler.java:96) at org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:76) at org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:61) at org.apache.james.protocols.smtp.core.ReceivedDataLineFilter.onLine(ReceivedDataLineFilter.java:54) at org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:76) at org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:61) at org.apache.james.protocols.smtp.core.esmtp.MailSizeEsmtpExtension.onLine(MailSizeEsmtpExtension.java:147) at org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:76) at org.apache.james.protocols.smtp.core.DataCmdHandler$DataLineFilterWrapper.onLine(DataCmdHandler.java:61) at org.apache.james.protocols.impl.LineHandlerUpstreamHandler.messageReceived(LineHandlerUpstreamHandler.java:57) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:545) at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:754) at org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:69) at org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecutor$ChildExecutor.run(OrderedMemoryAwareThreadPoolExecutor.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Caused by: javax.mail.internet.ParseException: Expected ';', got "windows-1250" at javax.mail.internet.ParameterList.(ParameterList.java:289) at javax.mail.internet.ContentType.(ContentType.java:114) at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1322) at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1021) at javax.mail.internet.MimeMultipart.updateHeaders(MimeMultipart.java:419) at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1345) at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1021) at javax.mail.internet.MimeMultipart.updateHeaders(MimeMultipart.java:419) at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1345) at javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2106) at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2074) at org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:295) at org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:290) at org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:286) at org.apache.james.core.MimeMessageWrapper.writeTo(MimeMessageWrapper.java:271) at org.apache.james.core.MimeMessageCopyOnWriteProxy.writeTo(MimeMessageCopyOnWriteProxy.java:184) at org.apache.james.queue.file.FileMailQueue.enQueue(FileMailQueue.java:161) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsub
[jira] [Resolved] (JAMES-1319) CamelMailetProcessor MAY use more threads as expected and so has some side-effects
[ https://issues.apache.org/jira/browse/JAMES-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1319. -- Resolution: Fixed > CamelMailetProcessor MAY use more threads as expected and so has some > side-effects > -- > > Key: JAMES-1319 > URL: https://issues.apache.org/jira/browse/JAMES-1319 > Project: JAMES Server > Issue Type: Bug > Components: SpoolManager & Processors >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > In CamelMailetProcessor we use parallel processing when splitting the mail > because of Matcher's. This leads to spawn extra threads within camel which is > not what most users expect. To mimic more the old behavoir and also make sure > we don't run into issues we should remove the parallel processing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1319) CamelMailetProcessor MAY use more threads as expected and so has some side-effects
CamelMailetProcessor MAY use more threads as expected and so has some side-effects -- Key: JAMES-1319 URL: https://issues.apache.org/jira/browse/JAMES-1319 Project: JAMES Server Issue Type: Bug Components: SpoolManager & Processors Affects Versions: 3.0-beta3 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 3.0-beta4 In CamelMailetProcessor we use parallel processing when splitting the mail because of Matcher's. This leads to spawn extra threads within camel which is not what most users expect. To mimic more the old behavoir and also make sure we don't run into issues we should remove the parallel processing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (IMAP-340) James don't preserve UID order when copying messages
[ https://issues.apache.org/jira/browse/IMAP-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107213#comment-13107213 ] Norman Maurer commented on IMAP-340: I think this should be moved to MAILBOX. > James don't preserve UID order when copying messages > > > Key: IMAP-340 > URL: https://issues.apache.org/jira/browse/IMAP-340 > Project: JAMES Imap > Issue Type: Bug > Components: Mailbox >Affects Versions: 0.2.1 >Reporter: Wojtek Strzalka >Assignee: Wojtek Strzalka > Fix For: 0.2.1 > > > When copying messages in bulks, mailbox implementation don't preserve UID's > order by usage of HashMap which don't guarantee elements order. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1318) RemoteDelivery tries to modify the returned Collection of Mail.getRecipients() directly
RemoteDelivery tries to modify the returned Collection of Mail.getRecipients() directly --- Key: JAMES-1318 URL: https://issues.apache.org/jira/browse/JAMES-1318 Project: JAMES Server Issue Type: Bug Reporter: Norman Maurer Priority: Critical In RemoteDelivery we try to modify the returned Collection of Mail.getRecipients() directly. This may fail because a Collection can be read-only as remove etc is an optional implementation. We need to copy it and then set it via Mail.setRecipients(..) to be 100% sure. See this related stack trace: INFO 17:41:25,409 | james.mailetcontext | Exception caught in RemoteDelivery.run() org.apache.james.queue.api.MailQueue$MailQueueException: Unable to perform dequeue; nested exception is: java.lang.UnsupportedOperationException at org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:768) at java.lang.Thread.run(Thread.java:679) Caused by: java.lang.UnsupportedOperationException at java.util.AbstractList.remove(AbstractList.java:161) at java.util.AbstractList$Itr.remove(AbstractList.java:375) at java.util.AbstractList.removeRange(AbstractList.java:572) at java.util.AbstractList.clear(AbstractList.java:234) at org.apache.james.transport.mailets.RemoteDelivery.deliver(RemoteDelivery.java:1132) at org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:718) ... 1 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (JAMES-1318) RemoteDelivery tries to modify the returned Collection of Mail.getRecipients() directly
[ https://issues.apache.org/jira/browse/JAMES-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated JAMES-1318: - Component/s: Matchers/Mailets (bundled) Affects Version/s: 3.0-beta3 Fix Version/s: 3.0-beta4 Assignee: Norman Maurer > RemoteDelivery tries to modify the returned Collection of > Mail.getRecipients() directly > --- > > Key: JAMES-1318 > URL: https://issues.apache.org/jira/browse/JAMES-1318 > Project: JAMES Server > Issue Type: Bug > Components: Matchers/Mailets (bundled) >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Assignee: Norman Maurer >Priority: Critical > Fix For: 3.0-beta4 > > > In RemoteDelivery we try to modify the returned Collection of > Mail.getRecipients() directly. This may fail because a Collection can be > read-only as remove etc is an optional implementation. We need to copy it and > then set it via Mail.setRecipients(..) to be 100% sure. > See this related stack trace: > INFO 17:41:25,409 | james.mailetcontext | Exception caught in > RemoteDelivery.run() > org.apache.james.queue.api.MailQueue$MailQueueException: Unable to perform > dequeue; > nested exception is: > java.lang.UnsupportedOperationException > at > org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:768) > at java.lang.Thread.run(Thread.java:679) > Caused by: java.lang.UnsupportedOperationException > at java.util.AbstractList.remove(AbstractList.java:161) > at java.util.AbstractList$Itr.remove(AbstractList.java:375) > at java.util.AbstractList.removeRange(AbstractList.java:572) > at java.util.AbstractList.clear(AbstractList.java:234) > at > org.apache.james.transport.mailets.RemoteDelivery.deliver(RemoteDelivery.java:1132) > at > org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:718) > ... 1 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1318) RemoteDelivery tries to modify the returned Collection of Mail.getRecipients() directly
[ https://issues.apache.org/jira/browse/JAMES-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1318. -- Resolution: Fixed > RemoteDelivery tries to modify the returned Collection of > Mail.getRecipients() directly > --- > > Key: JAMES-1318 > URL: https://issues.apache.org/jira/browse/JAMES-1318 > Project: JAMES Server > Issue Type: Bug > Components: Matchers/Mailets (bundled) >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Assignee: Norman Maurer >Priority: Critical > Fix For: 3.0-beta4 > > > In RemoteDelivery we try to modify the returned Collection of > Mail.getRecipients() directly. This may fail because a Collection can be > read-only as remove etc is an optional implementation. We need to copy it and > then set it via Mail.setRecipients(..) to be 100% sure. > See this related stack trace: > INFO 17:41:25,409 | james.mailetcontext | Exception caught in > RemoteDelivery.run() > org.apache.james.queue.api.MailQueue$MailQueueException: Unable to perform > dequeue; > nested exception is: > java.lang.UnsupportedOperationException > at > org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:768) > at java.lang.Thread.run(Thread.java:679) > Caused by: java.lang.UnsupportedOperationException > at java.util.AbstractList.remove(AbstractList.java:161) > at java.util.AbstractList$Itr.remove(AbstractList.java:375) > at java.util.AbstractList.removeRange(AbstractList.java:572) > at java.util.AbstractList.clear(AbstractList.java:234) > at > org.apache.james.transport.mailets.RemoteDelivery.deliver(RemoteDelivery.java:1132) > at > org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:718) > ... 1 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (PROTOCOLS-3) Add some reusable implementation code
[ https://issues.apache.org/jira/browse/PROTOCOLS-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved PROTOCOLS-3. --- Resolution: Fixed Fix Version/s: 1.6 I think this can get closed now > Add some reusable implementation code > - > > Key: PROTOCOLS-3 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-3 > Project: JAMES Protocols > Issue Type: Task >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 1.6 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (PROTOCOLS-28) Use zero-file-copy if possible in AbstractSession.writeStream(...)
[ https://issues.apache.org/jira/browse/PROTOCOLS-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved PROTOCOLS-28. Resolution: Won't Fix Writing a stream was removed from the abstract class > Use zero-file-copy if possible in AbstractSession.writeStream(...) > -- > > Key: PROTOCOLS-28 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-28 > Project: JAMES Protocols > Issue Type: Improvement >Affects Versions: 1.4.0 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 1.5 > > > We should make use of zero-file-copy if possible in > AbstractSession.writeStream(...) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (PROTOCOLS-30) STARTTLS handling is not correct and can cause touble execution of the STARTTLS handling
[ https://issues.apache.org/jira/browse/PROTOCOLS-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved PROTOCOLS-30. Resolution: Fixed done > STARTTLS handling is not correct and can cause touble execution of the > STARTTLS handling > > > Key: PROTOCOLS-30 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-30 > Project: JAMES Protocols > Issue Type: Bug > Components: api, smtp >Affects Versions: 1.5 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 1.6 > > > When we handler STARTTLS we are current write the Response to the client via > Session.write(...) , then trigger Session.startTLS() and then return null > from the CommandHandler. The problem is that returning null tells the > LineHandler to execute the next CommandHandler as it things we was not able > to handle the Request. It would be better to return a special type of > Response and let the linehandler/Session handle all the other parts -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (MAILBOX-134) MailboxListener may not removed even if MailboxListener.isClosed() is true
[ https://issues.apache.org/jira/browse/MAILBOX-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved MAILBOX-134. --- Resolution: Fixed > MailboxListener may not removed even if MailboxListener.isClosed() is true > -- > > Key: MAILBOX-134 > URL: https://issues.apache.org/jira/browse/MAILBOX-134 > Project: James Mailbox > Issue Type: Bug > Components: api, store >Affects Versions: 0.3 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.4 > > > At the moment we check on every new even for a specific mailbox if an > listener was closed before and if so we remove it. This is error-phrone and > also may lead to "leaking" MailboxListeners as if no new event for a Mailbox > will submitted it will there forever. > We should better directly remove the MailboxListener and not relay on a lazy > removal. This also should be a way faster as we don't need to check all > MailboxListeners for a Mailbox on every event -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (MAILBOX-134) MailboxListener may not removed even if MailboxListener.isClosed() is true
MailboxListener may not removed even if MailboxListener.isClosed() is true -- Key: MAILBOX-134 URL: https://issues.apache.org/jira/browse/MAILBOX-134 Project: James Mailbox Issue Type: Bug Components: api, store Affects Versions: 0.3 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.4 At the moment we check on every new even for a specific mailbox if an listener was closed before and if so we remove it. This is error-phrone and also may lead to "leaking" MailboxListeners as if no new event for a Mailbox will submitted it will there forever. We should better directly remove the MailboxListener and not relay on a lazy removal. This also should be a way faster as we don't need to check all MailboxListeners for a Mailbox on every event -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (PROTOCOLS-31) Add a simple netty bases SMTPServer implementation
Add a simple netty bases SMTPServer implementation -- Key: PROTOCOLS-31 URL: https://issues.apache.org/jira/browse/PROTOCOLS-31 Project: JAMES Protocols Issue Type: New Feature Components: smtp Affects Versions: 1.5 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 1.6 At the moment we only ship the api for the SMTP-Server + some transport independent stuff. It would be nice if we could also include some simple SMTPServer which can be used in an easy way. Something like subetha-smtp or mailster. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (PROTOCOLS-30) STARTTLS handling is not correct and can cause touble execution of the STARTTLS handling
STARTTLS handling is not correct and can cause touble execution of the STARTTLS handling Key: PROTOCOLS-30 URL: https://issues.apache.org/jira/browse/PROTOCOLS-30 Project: JAMES Protocols Issue Type: Bug Components: api, smtp Affects Versions: 1.5 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 1.6 When we handler STARTTLS we are current write the Response to the client via Session.write(...) , then trigger Session.startTLS() and then return null from the CommandHandler. The problem is that returning null tells the LineHandler to execute the next CommandHandler as it things we was not able to handle the Request. It would be better to return a special type of Response and let the linehandler/Session handle all the other parts -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1317) Mail spooled but not processed
[ https://issues.apache.org/jira/browse/JAMES-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13105856#comment-13105856 ] Norman Maurer commented on JAMES-1317: -- Could you please also attach the mailetcontainer.log* of the "hung" time.. Thanks, Norman > Mail spooled but not processed > -- > > Key: JAMES-1317 > URL: https://issues.apache.org/jira/browse/JAMES-1317 > Project: JAMES Server > Issue Type: Bug > Components: SpoolManager & Processors >Affects Versions: 3.0-M1, 3.0-M2, 3.0-beta3 >Reporter: Raju Buchi >Priority: Critical > Attachments: jstack.zip > > > Mails sent to James server are spooled but they are not processed and sent > out. > The issue is similar to the one faced by Zach. > The server seems to be working fine for a few hours or few days, but some > time all the mails are spooled but they will not be processed and sent out. > Restarted the server several times and some time a few of the mails will be > processed and all the others are lost. > As Norman suggested I have took a jstack trace. > Please let me how we can resolve this issue > Thanks > - Raju -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1316) Add a file based MailQueue implementation
Add a file based MailQueue implementation - Key: JAMES-1316 URL: https://issues.apache.org/jira/browse/JAMES-1316 Project: JAMES Server Issue Type: New Feature Components: Queue Affects Versions: 3.0-beta3 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 3.0-beta4 We should "switch back" to a file based MailQueue implementation as default as ActiveMQ just seems to be not stable enough for our needs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (PROTOCOLS-29) Remove ChannelLocal usage
[ https://issues.apache.org/jira/browse/PROTOCOLS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved PROTOCOLS-29. Resolution: Fixed > Remove ChannelLocal usage > - > > Key: PROTOCOLS-29 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-29 > Project: JAMES Protocols > Issue Type: Improvement >Affects Versions: 1.5 >Reporter: Norman Maurer >Assignee: Norman Maurer >Priority: Minor > Fix For: 1.6 > > > We currently use a ChannelLocal instance to store our Session object. This is > slow (as stated in the netty docs) so we should better get rid of it -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (PROTOCOLS-29) Remove ChannelLocal usage
Remove ChannelLocal usage - Key: PROTOCOLS-29 URL: https://issues.apache.org/jira/browse/PROTOCOLS-29 Project: JAMES Protocols Issue Type: Improvement Affects Versions: 1.5 Reporter: Norman Maurer Assignee: Norman Maurer Priority: Minor Fix For: 1.6 We currently use a ChannelLocal instance to store our Session object. This is slow (as stated in the netty docs) so we should better get rid of it -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1315) DataLineJamesMessageHookHandler does call OutputStream.flush() to often
[ https://issues.apache.org/jira/browse/JAMES-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1315. -- Resolution: Fixed > DataLineJamesMessageHookHandler does call OutputStream.flush() to often > --- > > Key: JAMES-1315 > URL: https://issues.apache.org/jira/browse/JAMES-1315 > Project: JAMES Server > Issue Type: Improvement > Components: SMTPServer >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Assignee: Norman Maurer >Priority: Minor > Fix For: 3.0-beta4 > > > In DataLineJamesMessageHookHandler we call OutputStream.flush() after each > line of data that we receive. This is a waste of performance as we only need > to flush it when we received the CRLF.CRLF sequence. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1315) DataLineJamesMessageHookHandler does call OutputStream.flush() to often
DataLineJamesMessageHookHandler does call OutputStream.flush() to often --- Key: JAMES-1315 URL: https://issues.apache.org/jira/browse/JAMES-1315 Project: JAMES Server Issue Type: Improvement Components: SMTPServer Affects Versions: 3.0-beta3 Reporter: Norman Maurer Assignee: Norman Maurer Priority: Minor Fix For: 3.0-beta4 In DataLineJamesMessageHookHandler we call OutputStream.flush() after each line of data that we receive. This is a waste of performance as we only need to flush it when we received the CRLF.CRLF sequence. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1314) HEADER.html file still refers to jakarta
[ https://issues.apache.org/jira/browse/JAMES-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104544#comment-13104544 ] Norman Maurer commented on JAMES-1314: -- Should be the one in the dist area on people.apaxhe.org. > HEADER.html file still refers to jakarta > > > Key: JAMES-1314 > URL: https://issues.apache.org/jira/browse/JAMES-1314 > Project: JAMES Server > Issue Type: Bug >Reporter: Sebb > > ./james/HEADER.html:Index of /dist/jakarta/james > Probably best to remove the entry entirely, as it does not strictly > apply to the subdirectories which link to the file -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1312) NullPointerException processing imap request
[ https://issues.apache.org/jira/browse/JAMES-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1312. -- Resolution: Fixed Assignee: Norman Maurer fixed.. The NPE was harmless as it was just thrown because the channel was already closed when try to decode missing bytes. Thanks for reporting > NullPointerException processing imap request > > > Key: JAMES-1312 > URL: https://issues.apache.org/jira/browse/JAMES-1312 > Project: JAMES Server > Issue Type: Bug > Components: IMAPServer >Affects Versions: 3.0-beta3 >Reporter: Nicola Salvemini >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > I found following exception during IMAP connection from blackberry client: > INFO 23:43:59,297 | james.imapserver | ID=1927897693 Connection established > from bda-178-239-84-174.bis7.eu.blackberry.com (178.239.84.174) > DEBUG 23:43:59,359 | james.imapserver | ID=1927897693 Got : c > DEBUG 23:43:59,360 | james.imapserver | ID=1927897693 Got : > CAPABILITY > DEBUG 23:43:59,360 | james.imapserver | ID=1927897693 No mailbox selected > DEBUG 23:43:59,380 | james.imapserver | ID=1927897693 Got : l > DEBUG 23:43:59,380 | james.imapserver | ID=1927897693 Got : LOGIN > DEBUG 23:43:59,383 | james.imapserver | ID=1927897693 INBOX exists. No need > to create it. > DEBUG 23:43:59,403 | james.imapserver | ID=1927897693 Got : l > DEBUG 23:43:59,403 | james.imapserver | ID=1927897693 Got : LIST > DEBUG 23:43:59,447 | james.imapserver | ID=1927897693 Got : s > DEBUG 23:43:59,447 | james.imapserver | ID=1927897693 Got : SELECT > DEBUG 23:43:59,448 | james.imapserver | ID=1927897693 Loaded mailbox > #private:i...@mydomain.net:INBOX > DEBUG 23:43:59,723 | james.imapserver | ID=1927897693 Got : q > DEBUG 23:43:59,723 | james.imapserver | ID=1927897693 Got : LOGOUT > INFO 23:43:59,723 | james.imapserver | ID=1927897693 Connection closed for > bda-178-239-84-174.bis7.eu.blackberry.com (178.239.84.174) > DEBUG 23:43:59,724 | james.imapserver | ID=1927897693 Error while processing > imap request > java.lang.NullPointerException > at > org.apache.james.imap.decode.main.DefaultImapDecoder.decode(DefaultImapDecoder.java:69) > at > org.apache.james.imapserver.netty.ImapRequestFrameDecoder.decode(ImapRequestFrameDecoder.java:161) > at > org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:282) > at > org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:216) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302) > at > org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:317) > at > org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:299) > at > org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:216) > at > org.jboss.netty.handler.timeout.IdleStateAwareChannelHandler.handleUpstream(IdleStateAwareChannelHandler.java:48) > at > org.jboss.netty.handler.timeout.IdleStateHandler.messageReceived(IdleStateHandler.java:276) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302) > at > org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:317) > at > org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:299) > at > org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:216) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261) > at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:90) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (JSPF-93) FutureSPFResult.isReady() MUST be synchronized
[ https://issues.apache.org/jira/browse/JSPF-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated JSPF-93: -- Priority: Minor (was: Major) > FutureSPFResult.isReady() MUST be synchronized > -- > > Key: JSPF-93 > URL: https://issues.apache.org/jira/browse/JSPF-93 > Project: JAMES jSPF > Issue Type: Bug > Components: Core >Affects Versions: 0.9.9 >Reporter: Norman Maurer >Assignee: Norman Maurer >Priority: Minor > Fix For: 1.0 > > > We MUST synchronize FutureSPFResult.isReady() to avoid race-conditions -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JSPF-93) FutureSPFResult.isReady() MUST be synchronized
[ https://issues.apache.org/jira/browse/JSPF-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JSPF-93. --- Resolution: Fixed > FutureSPFResult.isReady() MUST be synchronized > -- > > Key: JSPF-93 > URL: https://issues.apache.org/jira/browse/JSPF-93 > Project: JAMES jSPF > Issue Type: Bug > Components: Core >Affects Versions: 0.9.9 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 1.0 > > > We MUST synchronize FutureSPFResult.isReady() to avoid race-conditions -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JSPF-93) FutureSPFResult.isReady() MUST be synchronized
FutureSPFResult.isReady() MUST be synchronized -- Key: JSPF-93 URL: https://issues.apache.org/jira/browse/JSPF-93 Project: JAMES jSPF Issue Type: Bug Components: Core Affects Versions: 0.9.9 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 1.0 We MUST synchronize FutureSPFResult.isReady() to avoid race-conditions -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1313) more effective getUserByName(String name) in org.apache.james.user.ldap.ReadOnlyUsersLDAPRepository
[
https://issues.apache.org/jira/browse/JAMES-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13102640#comment-13102640
]
Norman Maurer commented on JAMES-1313:
--
Could you upload the patch as diff and check the ASF grant box ?
> more effective getUserByName(String name) in
> org.apache.james.user.ldap.ReadOnlyUsersLDAPRepository
>
>
> Key: JAMES-1313
> URL: https://issues.apache.org/jira/browse/JAMES-1313
> Project: JAMES Server
> Issue Type: Improvement
> Components: UsersStore & UsersRepository
>Affects Versions: 3.0-beta3
>Reporter: Peter Kvokacka
>Priority: Minor
> Labels: patch
> Fix For: 3.0-beta3
>
>
> Hello
> I'd like to use james in my current project, but I find LDAP implementation
> of usersRepository to be not very effective.
> Especially method getUserByName(String name) in
> org.apache.james.user.ldap.ReadOnlyUsersLDAPRepository seems to search all
> users in LDAP with userBase and after that it goes through the result in
> memory and looking for specific user. Which produce search like this with
> potencialy big resultset:
> SEARCH REQ conn=26 op=6 msgID=7 base="ou=people,dc=mycompany,dc=sk"
> scope=wholeSubtree filter="(objectClass=inetOrgPerson)"
> attrs="distinguishedName"
> SEARCH RES conn=26 op=6 msgID=7 result=0 nentries=438 etime=169
> SEARCH REQ conn=26 op=7 msgID=8
> base="uid=somebody,ou=people,dc=mycompany,dc=sk" scope=baseObject
> filter="(objectClass=*)" attrs="ALL"
> SEARCH RES conn=26 op=7 msgID=8 result=0 nentries=1 etime=1
> ... X more, where X is size-1 of userBase subtree
> I suggest a patch that (at least in my case) does simple search instead:
> class="org.apache.james.user.ldap.ReadOnlyUsersLDAPRepository"
> ldapHost="ldaps://ldap.mycomapny.local:1636"
> principal="cn=admin"
> credentials="***"
> userBase="ou=people,dc=mycompany,dc=sk"
> userIdAttribute="uid"
> userObjectClass="inetOrgPerson"/>
> SEARCH REQ conn=26 op=1 msgID=2
> base="uid=test0123,ou=people,dc=mycompany,dc=sk" scope=baseObject
> filter="(objectClass=inetOrgPerson)" attrs="uid"
> SEARCH RES conn=26 op=1 msgID=2 result=0 nentries=1 etime=1
> There is only one assumption that distinguishedName for each entry in
> userBase is "userIdAttribute=$name,userBase", where $name is username. I
> don't think of it as of a strong restriction, but you should consider that
> and decide for yourself. It works just fine for me.
> Also it looks like getUserByNameCaseInsensitive(String name) is not used
> anywhere, so you can stick with current implementation for now.
> Peter
> Index:
> src/main/java/org/apache/james/user/ldap/ReadOnlyUsersLDAPRepository.java
> ===
> --- src/main/java/org/apache/james/user/ldap/ReadOnlyUsersLDAPRepository.java
> (revision 1169673)
> +++ src/main/java/org/apache/james/user/ldap/ReadOnlyUsersLDAPRepository.java
> (working copy)
> @@ -351,16 +351,23 @@
> * Propagated by the underlying LDAP communication layer.
> */
> private ReadOnlyLDAPUser buildUser(String userDN) throws NamingException
> {
> -ReadOnlyLDAPUser result;
>
> -Attributes userAttributes =
> ldapConnection.getLdapContext().getAttributes(userDN);
> +SearchControls sc = new SearchControls();
> +sc.setSearchScope(SearchControls.OBJECT_SCOPE);
> +sc.setReturningAttributes(new String[] {userIdAttribute});
> +sc.setCountLimit(1);
> +
> +NamingEnumeration sr =
> ldapConnection.getLdapContext().search(userDN, "(objectClass=" +
> userObjectClass + ")", sc);
> +
> +if (!sr.hasMore())
> +return null;
> +
> +Attributes userAttributes = sr.next().getAttributes();
> Attribute userName = userAttributes.get(userIdAttribute);
> +
> +return new ReadOnlyLDAPUser(userName.get().toString(), userDN,
> ldapHost);
> + }
>
> -result = new ReadOnlyLDAPUser(userName.get().toString(), userDN,
> ldapHost);
> -
> -return result;
> -}
> -
> /*
> * (non-Javadoc)
> *
> @@ -425,23 +432,14 @@
> */
> public User getUserByName(String name) throws UsersRepositoryException {
> try {
> -Iterator userIt =
> buildUserCollection(getValidUsers()).iterator();
> -while (userIt.hasNext()) {
> -ReadOnlyLDAPUser u = userIt.next();
> -if (u.getUserName().equals(name)) {
> -return u;
> -}
> -}
> -
> +return buildUser(userIdAttribute + "=" + name + "," + userBase);
> } catch (NamingException
[jira] [Created] (JSPF-92) @Deprecate FutureSPFResult
@Deprecate FutureSPFResult -- Key: JSPF-92 URL: https://issues.apache.org/jira/browse/JSPF-92 Project: JAMES jSPF Issue Type: Improvement Components: Core Affects Versions: 0.9.9 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 1.0 We should @deprecate FutureSPFResult and add an implementation which implements java.concurent.Future -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1311) RemoteDelivery should allow to handle new emails with higher priority
[ https://issues.apache.org/jira/browse/JAMES-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1311. -- Resolution: Fixed Fix Version/s: 3.0-beta4 Allow to set "usePriority" as RemoteDelivery config param to give new mails higher prioritity then retries > RemoteDelivery should allow to handle new emails with higher priority > - > > Key: JAMES-1311 > URL: https://issues.apache.org/jira/browse/JAMES-1311 > Project: JAMES Server > Issue Type: New Feature > Components: Remote Delivery >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > At the moment we don't do any priority like handling of emails when > dequeue/queue them via RemoteDelivery. So retry emails can block new emails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1311) RemoteDelivery should allow to handle new emails with higher priority
RemoteDelivery should allow to handle new emails with higher priority - Key: JAMES-1311 URL: https://issues.apache.org/jira/browse/JAMES-1311 Project: JAMES Server Issue Type: New Feature Components: Remote Delivery Affects Versions: 3.0-beta3 Reporter: Norman Maurer Assignee: Norman Maurer At the moment we don't do any priority like handling of emails when dequeue/queue them via RemoteDelivery. So retry emails can block new emails. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1207) Avoid file descriptor leaks
[
https://issues.apache.org/jira/browse/JAMES-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098762#comment-13098762
]
Norman Maurer commented on JAMES-1207:
--
Yeah just close them..
> Avoid file descriptor leaks
> ---
>
> Key: JAMES-1207
> URL: https://issues.apache.org/jira/browse/JAMES-1207
> Project: JAMES Server
> Issue Type: Task
>Affects Versions: Trunk
> Environment: All
>Reporter: Felix Knecht
>Assignee: Felix Knecht
>
> Make sure, created streams get closed at least in a finally block to avoid
> file descriptor leaks. E.g. in code below it's not known if LineNumberReader
> closed the given created stream
> try {
> LineNumberReader counter;
> if (getEncoding() != null) {
> counter = new LineNumberReader(new InputStreamReader(in,
> getEncoding()));
> } else {
> counter = new LineNumberReader(new InputStreamReader(in));
> }
> //Read through all the data
> char[] block = new char[4096];
> while (counter.read(block) > -1) {
> //Just keep reading
> }
> return counter.getLineNumber();
> } catch (IOException ioe) {
> return -1;
> } finally {
> IOUtils.closeQuietly(in);
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1207) Avoid file descriptor leaks
[
https://issues.apache.org/jira/browse/JAMES-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098700#comment-13098700
]
Norman Maurer commented on JAMES-1207:
--
@Felix:
Do you have time to review and fix ?
> Avoid file descriptor leaks
> ---
>
> Key: JAMES-1207
> URL: https://issues.apache.org/jira/browse/JAMES-1207
> Project: JAMES Server
> Issue Type: Task
>Affects Versions: Trunk
> Environment: All
>Reporter: Felix Knecht
>
> Make sure, created streams get closed at least in a finally block to avoid
> file descriptor leaks. E.g. in code below it's not known if LineNumberReader
> closed the given created stream
> try {
> LineNumberReader counter;
> if (getEncoding() != null) {
> counter = new LineNumberReader(new InputStreamReader(in,
> getEncoding()));
> } else {
> counter = new LineNumberReader(new InputStreamReader(in));
> }
> //Read through all the data
> char[] block = new char[4096];
> while (counter.read(block) > -1) {
> //Just keep reading
> }
> return counter.getLineNumber();
> } catch (IOException ioe) {
> return -1;
> } finally {
> IOUtils.closeQuietly(in);
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (JAMES-1259) Problem sending email to local and non-local recipients with Camel 2.6.0
[ https://issues.apache.org/jira/browse/JAMES-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated JAMES-1259: - Assignee: Norman Maurer Summary: Problem sending email to local and non-local recipients with Camel 2.6.0 (was: Problem sending email to local and non-local recipients) > Problem sending email to local and non-local recipients with Camel 2.6.0 > > > Key: JAMES-1259 > URL: https://issues.apache.org/jira/browse/JAMES-1259 > Project: JAMES Server > Issue Type: Bug > Components: SMTPServer >Affects Versions: 3.0-beta3 >Reporter: Nicola Salvemini >Assignee: Norman Maurer >Priority: Critical > > James is not able to deliver email having local recipient in CC. When it try, > the email remains in "store/activemq/blob-transfer/" and cpu rising to 100%. > From this point on, James is not able to send any mail. All emails remain in > "store/activemq/blob-transfer/" until OOM is reached. To resolve it's > necessary delete email in "store/activemq/blob-transfer/" and restart the > server. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-980) Fix the possibility to build submodules only
[ https://issues.apache.org/jira/browse/JAMES-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-980. - Resolution: Fixed Fix Version/s: 3.0-beta4 Assignee: Norman Maurer It seems to work for me now > Fix the possibility to build submodules only > - > > Key: JAMES-980 > URL: https://issues.apache.org/jira/browse/JAMES-980 > Project: JAMES Server > Issue Type: Bug > Components: Build System >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > At the moment its only possible to build james when do the build in the root > folder of it. It should be possible to only build a submodule by change into > it and execute the build there.. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1285) Custom mailet not working
[ https://issues.apache.org/jira/browse/JAMES-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1285. -- Resolution: Cannot Reproduce Fix Version/s: 3.0-beta4 Assignee: Norman Maurer Please reopen if its still an issue > Custom mailet not working > - > > Key: JAMES-1285 > URL: https://issues.apache.org/jira/browse/JAMES-1285 > Project: JAMES Server > Issue Type: Bug > Components: Matchers/Mailets (bundled) >Affects Versions: 3.0-M2 >Reporter: Raju Buchi >Assignee: Norman Maurer >Priority: Critical > Labels: moved_from_2.3.2_to_3.0-M2, newbie > Fix For: 3.0-beta4 > > > Hello > I have recently created a new server where I have got James 3.0-M2 running. I > was able to start up James normally and send emails from it before I > configured the custom mailet in mailetcontainer.xml. > This is what I did: > I have modified mailercontainer.xml to include custom mailerpackage and > matcherpackage. > --- > > 25 > > org.apache.james.transport.mailets > org.apache.james.mailet.crypto.mailet > org.apache.james.imapserver.sieve > > com.intelliun.util.james.maillet.VECallBack > > > org.apache.james.transport.matchers > org.apache.james.mailet.crypto.matchers > > org.apache.james.mailetcontainer.lib.matchers > > com.intelliun.util.james.matcher.NewsletterBounceMatcher > > > > > > > http://webop.mywebsite.net/~web/newsletter/trackEmailBounce.v > > > transport > > --- > I have included the jar file in /conf/lib folder. This was used in James > 2.3.2 version and worked fine. > When I restart the server after I made these modifications, I get the > following error: > .. > ERROR 11:45:40,037 | james.mailetcontainer | Unable to init matcher > NewsletterBounceMatcher=cpwebopnp: org.apache.mailet.MailetException: Could > not load matcher (NewsletterBounceMatcher); > nested exception is: > java.lang.ClassNotFoundException: Requested matcher not found: > NewsletterBounceMatcher. Package searched: > org.apache.james.transport.matchers. org.apache.james.mailet.crypto.matchers. > org.apache.james.mailetcontainer.lib.matchers. > com.intelliun.util.james.matcher.NewsletterBounceMatcher. > org.apache.mailet.MailetException: Could not load matcher > (NewsletterBounceMatcher); > nested exception is: > java.lang.ClassNotFoundException: Requested matcher not found: > NewsletterBounceMatcher. Package searched: > org.apache.james.transport.matchers. org.apache.james.mailet.crypto.matchers. > org.apache.james.mailetcontainer.lib.matchers. > com.intelliun.util.james.matcher.NewsletterBounceMatcher. > at > org.apache.james.mailetcontainer.lib.AbstractLoader.loadFailed(AbstractLoader.java:138) > .. > Can please let me know how I could resolve this? > - Raju -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (IMAP-322) Allow to enable/disable CAPABILITIES from config
[ https://issues.apache.org/jira/browse/IMAP-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated IMAP-322: --- Fix Version/s: 0.3 Let us fix this before the next release > Allow to enable/disable CAPABILITIES from config > > > Key: IMAP-322 > URL: https://issues.apache.org/jira/browse/IMAP-322 > Project: JAMES Imap > Issue Type: New Feature >Reporter: Norman Maurer >Assignee: Norman Maurer >Priority: Minor > Fix For: 0.3 > > > At the moment we don't allow to enable/disable CAPABILTIES in any way. > Sometimes it would be nice to for example disable UIDPLUS handling at all. We > should expose some API todo so. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-11) MailboxQuery ignore namespace
[ https://issues.apache.org/jira/browse/MAILBOX-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098662#comment-13098662 ] Norman Maurer commented on MAILBOX-11: -- we shouldmfix it now > MailboxQuery ignore namespace > - > > Key: MAILBOX-11 > URL: https://issues.apache.org/jira/browse/MAILBOX-11 > Project: James Mailbox > Issue Type: Bug > Environment: Linux, JDK 1.6 >Reporter: François-Denis Gonthier >Assignee: Norman Maurer > Fix For: 0.4 > > > MailboxQuery doesn't pay any attention to namespace of the mailbox it is > based on. For example, Mozilla Thunderbird might to mailbox search with > expressions like #private.%. That expression is passed directly to the > isExpressionMatch method of the MailboxQuery class. This has obviously > incorrect results. > Arguments to the isExpressionMatch method should be parsed to separate the > namespace from the mailbox name or isExpressionMatch should do the parsing > itself. In that case the argument name should be renamed to something like > 'searchExpression' instead of 'name' which doesn't convey the right meaning. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-83) Add support for SOLR based MessageSearchIndex
[ https://issues.apache.org/jira/browse/MAILBOX-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098661#comment-13098661 ] Norman Maurer commented on MAILBOX-83: -- Any takers ? If not I would prolly put it on my todo list.. > Add support for SOLR based MessageSearchIndex > - > > Key: MAILBOX-83 > URL: https://issues.apache.org/jira/browse/MAILBOX-83 > Project: James Mailbox > Issue Type: New Feature >Reporter: Norman Maurer >Assignee: Norman Maurer > > It would be nice if we would also support SOLR for the MessageSearchIndex -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (MAILBOX-130) JPA restore functionality is not working with Encryption enabled.
[ https://issues.apache.org/jira/browse/MAILBOX-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved MAILBOX-130. --- Resolution: Fixed This should now work > JPA restore functionality is not working with Encryption enabled. > - > > Key: MAILBOX-130 > URL: https://issues.apache.org/jira/browse/MAILBOX-130 > Project: James Mailbox > Issue Type: Bug > Components: jpa mailbox >Affects Versions: 0.4 > Environment: Any environment Linux/Windows with Apache James 3 Beta 2 > release and nightly version of mailbox-jpa >Reporter: Valluripalli, Sai >Assignee: Norman Maurer > Labels: patch > Fix For: 0.4 > > Original Estimate: 6h > Remaining Estimate: 6h > > We are trying to restore data from 3.0-SNAPSHOT version to James 3-beta2 > upgraded version and restore always fails. May be this is related to > MAILBOX-129. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (MAILBOX-129) JPA Unable to move emails between folders
[ https://issues.apache.org/jira/browse/MAILBOX-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved MAILBOX-129. --- Resolution: Fixed Was fixed.. Thanks for the patch > JPA Unable to move emails between folders > - > > Key: MAILBOX-129 > URL: https://issues.apache.org/jira/browse/MAILBOX-129 > Project: James Mailbox > Issue Type: Bug > Components: jpa mailbox >Affects Versions: 0.4 > Environment: Any environment >Reporter: Valluripalli, Sai >Assignee: Norman Maurer >Priority: Blocker > Labels: patch > Fix For: 0.4 > > Original Estimate: 4h > Remaining Estimate: 4h > > With Encryption enabled we are unable to move email content between folders. > Example from sent to trash or inbox to draft etc.., -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (IMAP-334) Only use one Thread for Idle keep-alives
[ https://issues.apache.org/jira/browse/IMAP-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-334. Resolution: Invalid Fix Version/s: 0.3 I was wrong.. we use a pool > Only use one Thread for Idle keep-alives > > > Key: IMAP-334 > URL: https://issues.apache.org/jira/browse/IMAP-334 > Project: JAMES Imap > Issue Type: Improvement > Components: Protocol >Reporter: Norman Maurer >Assignee: Norman Maurer >Priority: Minor > Fix For: 0.3 > > > At the moment we schedule one thread per connection for keep alives. We > should better use a pool of x threads for the keep alives so we don't have > the one thread per connection overhead all the time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (IMAP-335) Review synchronization / locking
[ https://issues.apache.org/jira/browse/IMAP-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-335. Resolution: Fixed I think thats done > Review synchronization / locking > > > Key: IMAP-335 > URL: https://issues.apache.org/jira/browse/IMAP-335 > Project: JAMES Imap > Issue Type: Improvement >Affects Versions: 0.2.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.3 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (IMAP-319) MS Outlook returns "UID does not comply with standard"
[ https://issues.apache.org/jira/browse/IMAP-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-319. Resolution: Fixed Fix Version/s: 0.3 Fixed by MAILBOX-131 > MS Outlook returns "UID does not comply with standard" > -- > > Key: IMAP-319 > URL: https://issues.apache.org/jira/browse/IMAP-319 > Project: JAMES Imap > Issue Type: Bug > Components: JPA Mailbox >Affects Versions: 0.3 > Environment: Running James Beta-1 and Beta-2. Linux CentOS 5.5 > x86_64. > Java 1.6.0_23: Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode) >Reporter: Patrick Pyette > Fix For: 0.3 > > Attachments: MS Outlook UID Issue - No SSL.pcap, MS Outlook UID > Issue.pcap > > > When at some point, when sending and receiving email using an Outlook client > on a newly-created account, we receive the message: > "Your server has reported a UID which does not comply with the IMAP > standard." MsgSeqNum x, New UID y, Prev UID: x, Next UID: 0.". > This is consistent and repeatable for any jpa mailbox that we have tried. > Removing the account from Outlook, restarting, and adding it back in does not > clear the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (MAILBOX-131) MessageManager.append(...) MUST return a higher uid on each call
[ https://issues.apache.org/jira/browse/MAILBOX-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved MAILBOX-131. --- Resolution: Fixed Done by using the MailboxPathLocker for appends > MessageManager.append(...) MUST return a higher uid on each call > > > Key: MAILBOX-131 > URL: https://issues.apache.org/jira/browse/MAILBOX-131 > Project: James Mailbox > Issue Type: Bug > Components: api, store >Affects Versions: 0.3 >Reporter: Norman Maurer >Assignee: Norman Maurer >Priority: Critical > Fix For: 0.4 > > > To be compliant with the IMAP rfc its a MUST to return a higher uid on each > append(..) call. This is not the case atm. We just make sure we return a > unique one which is not enough and may lead to out of order events. This out > of order events confuse the hell out of outlook. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (MAILBOX-131) MessageManager.append(...) MUST return a higher uid on each call
MessageManager.append(...) MUST return a higher uid on each call Key: MAILBOX-131 URL: https://issues.apache.org/jira/browse/MAILBOX-131 Project: James Mailbox Issue Type: Bug Components: api, store Affects Versions: 0.3 Reporter: Norman Maurer Assignee: Norman Maurer Priority: Critical Fix For: 0.4 To be compliant with the IMAP rfc its a MUST to return a higher uid on each append(..) call. This is not the case atm. We just make sure we return a unique one which is not enough and may lead to out of order events. This out of order events confuse the hell out of outlook. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (IMAP-319) MS Outlook returns "UID does not comply with standard"
[ https://issues.apache.org/jira/browse/IMAP-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095522#comment-13095522 ] Norman Maurer commented on IMAP-319: I think I have an idea now what may cause the problem. I will try to get a fix ready on the weekend.. So stay tuned > MS Outlook returns "UID does not comply with standard" > -- > > Key: IMAP-319 > URL: https://issues.apache.org/jira/browse/IMAP-319 > Project: JAMES Imap > Issue Type: Bug > Components: JPA Mailbox >Affects Versions: 0.3 > Environment: Running James Beta-1 and Beta-2. Linux CentOS 5.5 > x86_64. > Java 1.6.0_23: Java HotSpot(TM) 64-Bit Server VM (build 19.0-b09, mixed mode) >Reporter: Patrick Pyette > Attachments: MS Outlook UID Issue - No SSL.pcap, MS Outlook UID > Issue.pcap > > > When at some point, when sending and receiving email using an Outlook client > on a newly-created account, we receive the message: > "Your server has reported a UID which does not comply with the IMAP > standard." MsgSeqNum x, New UID y, Prev UID: x, Next UID: 0.". > This is consistent and repeatable for any jpa mailbox that we have tried. > Removing the account from Outlook, restarting, and adding it back in does not > clear the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1307) RemoteDelivery does not send a permanent error on 5xx during HELO/EHLO
RemoteDelivery does not send a permanent error on 5xx during HELO/EHLO -- Key: JAMES-1307 URL: https://issues.apache.org/jira/browse/JAMES-1307 Project: JAMES Server Issue Type: Bug Components: Remote Delivery Affects Versions: 3.0-beta3 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 3.0-beta4 Here is the stacktrace (costumized RemoteDelivery): INFO 06:33:46,594 | james.mailetcontext | Remotely delivering mail Mail1314354826187-a85689d4-03b3-47ca-8bb3-6e059ec8a464 INFO 06:33:46,612 | james.mailetcontext | Sending mail to [xxx@xxx] via null INFO 06:33:46,633 | james.mailetcontext | Remote delivery thread (5) will process mail Mail1314354826187-a85689d4-03b3-47ca-8bb3-6e059ec8a464 INFO 06:33:46,633 | james.mailetcontext | Attempting to deliver Mail1314354826187-a85689d4-03b3-47ca-8bb3-6e059ec8a464 INFO 06:33:46,644 | james.mailetcontext | Attempting delivery of Mail1314354826187-a85689d4-03b3-47ca-8bb3-6e059ec8a464 to host xxx at xxx from x...@xxx.com for addresses [xxx@xxx] DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems, Inc] DEBUG SMTP: useEhlo true, useAuth false DEBUG SMTP: trying to connect to host "xxx", port 25, isSSL false 220 xxx 54 DEBUG SMTP: connected to host "xxx", port: 25 EHLO localhost 501 Fraudulent EHLO/HELO HELO localhost DEBUG SMTP: EOF: [EOF] INFO 06:33:47,467 | james.mailetcontext | [EOF] INFO 06:33:47,468 | james.mailetcontext | Temporary exception delivering mail (Mail1314354826187-a85689d4-03b3-47ca-8bb3-6e059ec8a464: javax.mail.MessagingException: No mail server(s) available at this time. at xxx.SlpRemoteDelivery.deliver(SlpRemoteDelivery.java:1296) at xxx.SlpRemoteDelivery.run(SlpRemoteDelivery.java:808) at java.lang.Thread.run(Thread.java:662) INFO 06:33:47,468 | james.mailetcontext | Storing message Mail1314354826187-a85689d4-03b3-47ca-8bb3-6e059ec8a464 into outgoing after 0 retries INFO 06:33:47,481 | james.mailetcontext | Remote delivery thread (5) will try to dequeue a mail -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1306) Zero-file-copy MAY only be used when COMPRESS is not activated
[ https://issues.apache.org/jira/browse/JAMES-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1306. -- Resolution: Fixed > Zero-file-copy MAY only be used when COMPRESS is not activated > -- > > Key: JAMES-1306 > URL: https://issues.apache.org/jira/browse/JAMES-1306 > Project: JAMES Server > Issue Type: Bug > Components: IMAPServer >Affects Versions: 3.0-beta4 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > Zero-file-copy can only be used if no COMPRESS is in place. Otherwise we need > to copy the bytes into memory for actual doing the compression -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1306) Zero-file-copy MAY only be used when COMPRESS is not activated
Zero-file-copy MAY only be used when COMPRESS is not activated -- Key: JAMES-1306 URL: https://issues.apache.org/jira/browse/JAMES-1306 Project: JAMES Server Issue Type: Bug Components: IMAPServer Affects Versions: 3.0-beta4 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 3.0-beta4 Zero-file-copy can only be used if no COMPRESS is in place. Otherwise we need to copy the bytes into memory for actual doing the compression -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Assigned] (IMAP-328) Better handle concurrent FETCH and EXPUNGE
[ https://issues.apache.org/jira/browse/IMAP-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer reassigned IMAP-328: -- Assignee: Norman Maurer > Better handle concurrent FETCH and EXPUNGE > -- > > Key: IMAP-328 > URL: https://issues.apache.org/jira/browse/IMAP-328 > Project: JAMES Imap > Issue Type: Improvement >Affects Versions: 0.2.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > > At the moment it MAY be possible for clients which do "slow" FETCHES to fail > during stream the message content back to the client of another client (or > session) EXPUNGE the same message at the same time. From a talk at ##imap > (freenode irc) other IMAP Server implementations handle this kind of stuff > more sensible (like dovecot and cyrus). > There are a few options to handle this kind of stuff: > 1) Lock the mailbox during FETCH and block EXPUNGE until its done > 2) Only do a "pseudo" expunge and add it to some "commitlog" which will get > executed when the FETCH is done. To be 100 % sure its necessary to store it > permanet but I think in most cases a in memory representation MAY be enough > I think 2) is the way to go -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (IMAP-330) Convert mailboxnames to UTF-8 before pass them to the Mailbox impl
[ https://issues.apache.org/jira/browse/IMAP-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-330. Resolution: Fixed Fixed.. thanks for catching this! > Convert mailboxnames to UTF-8 before pass them to the Mailbox impl > -- > > Key: IMAP-330 > URL: https://issues.apache.org/jira/browse/IMAP-330 > Project: JAMES Imap > Issue Type: Improvement >Affects Versions: 0.2.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.3 > > > IMAP use a modified UTF-7 to handle mailboxnames. At the moment we just use > the mailboxname as passed by the imap client to do any mailbox action. This > works but can be quite confusing if someone tries to lookup a mailbox via the > mailbox api and just pass the "real name" to it. > It would be better to convert from UTF-7 to UTF-8 before pass it to the > mailbox impl. > See http://fetchmail.berlios.de/Mailbox-Names-UTF7.html for some useful info -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1305) Zero-file-copy MAY only be used when no TLS/SSL is active
[ https://issues.apache.org/jira/browse/JAMES-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1305. -- Resolution: Fixed > Zero-file-copy MAY only be used when no TLS/SSL is active > - > > Key: JAMES-1305 > URL: https://issues.apache.org/jira/browse/JAMES-1305 > Project: JAMES Server > Issue Type: Bug > Components: IMAPServer, POP3Server, SMTPServer >Affects Versions: 3.0-beta4 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > We need to change the code so Zero-fily-copy MAY only be used if no > encryption is in place as we need to copy the content into memory for doing > the encryption -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (JAMES-1305) Zero-file-copy MAY only be used when no TLS/SSL is active
[ https://issues.apache.org/jira/browse/JAMES-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated JAMES-1305: - Component/s: SMTPServer POP3Server IMAPServer Affects Version/s: 3.0-beta4 Fix Version/s: 3.0-beta4 Assignee: Norman Maurer > Zero-file-copy MAY only be used when no TLS/SSL is active > - > > Key: JAMES-1305 > URL: https://issues.apache.org/jira/browse/JAMES-1305 > Project: JAMES Server > Issue Type: Bug > Components: IMAPServer, POP3Server, SMTPServer >Affects Versions: 3.0-beta4 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > We need to change the code so Zero-fily-copy MAY only be used if no > encryption is in place as we need to copy the content into memory for doing > the encryption -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1305) Zero-file-copy MAY only be used when no TLS/SSL is active
Zero-file-copy MAY only be used when no TLS/SSL is active - Key: JAMES-1305 URL: https://issues.apache.org/jira/browse/JAMES-1305 Project: JAMES Server Issue Type: Bug Reporter: Norman Maurer We need to change the code so Zero-fily-copy MAY only be used if no encryption is in place as we need to copy the content into memory for doing the encryption -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (IMAP-330) Convert mailboxnames to UTF-8 before pass them to the Mailbox impl
[ https://issues.apache.org/jira/browse/IMAP-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-330. Resolution: Fixed Done... > Convert mailboxnames to UTF-8 before pass them to the Mailbox impl > -- > > Key: IMAP-330 > URL: https://issues.apache.org/jira/browse/IMAP-330 > Project: JAMES Imap > Issue Type: Improvement >Affects Versions: 0.2.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.3 > > > IMAP use a modified UTF-7 to handle mailboxnames. At the moment we just use > the mailboxname as passed by the imap client to do any mailbox action. This > works but can be quite confusing if someone tries to lookup a mailbox via the > mailbox api and just pass the "real name" to it. > It would be better to convert from UTF-7 to UTF-8 before pass it to the > mailbox impl. > See http://fetchmail.berlios.de/Mailbox-Names-UTF7.html for some useful info -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Assigned] (IMAP-322) Allow to enable/disable CAPABILITIES from config
[ https://issues.apache.org/jira/browse/IMAP-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer reassigned IMAP-322: -- Assignee: Norman Maurer > Allow to enable/disable CAPABILITIES from config > > > Key: IMAP-322 > URL: https://issues.apache.org/jira/browse/IMAP-322 > Project: JAMES Imap > Issue Type: New Feature >Reporter: Norman Maurer >Assignee: Norman Maurer >Priority: Minor > > At the moment we don't allow to enable/disable CAPABILTIES in any way. > Sometimes it would be nice to for example disable UIDPLUS handling at all. We > should expose some API todo so. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1300) Deactive IMAP IDLE keep-alives
[ https://issues.apache.org/jira/browse/JAMES-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1300. -- Resolution: Won't Fix This will not work as we only send keep-alives when a command is active > Deactive IMAP IDLE keep-alives > -- > > Key: JAMES-1300 > URL: https://issues.apache.org/jira/browse/JAMES-1300 > Project: JAMES Server > Issue Type: Improvement > Components: IMAPServer >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Assignee: Norman Maurer >Priority: Minor > Fix For: 3.0-beta4 > > > The IdleProcessor sends IDLE keep-alives every x seconds by default. As we > send Keep alives on all commands we can disable these IDLE keep-alives to > save some resources / threads. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (IMAP-338) DefaultImapProcessorFactory should allow to disable IDLE keep-alives
[ https://issues.apache.org/jira/browse/IMAP-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-338. Resolution: Fixed > DefaultImapProcessorFactory should allow to disable IDLE keep-alives > > > Key: IMAP-338 > URL: https://issues.apache.org/jira/browse/IMAP-338 > Project: JAMES Imap > Issue Type: Task > Components: Processor >Affects Versions: 0.2.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.3 > > > IdleProcessor allows to disable IDLE keep-alives. So we should also allow to > disable it via DefaultImapProcessorFactory -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (IMAP-338) DefaultImapProcessorFactory should allow to disable IDLE keep-alives
DefaultImapProcessorFactory should allow to disable IDLE keep-alives Key: IMAP-338 URL: https://issues.apache.org/jira/browse/IMAP-338 Project: JAMES Imap Issue Type: Task Components: Processor Affects Versions: 0.2.1 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.3 IdleProcessor allows to disable IDLE keep-alives. So we should also allow to disable it via DefaultImapProcessorFactory -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (IMAP-292) SEARCH is not handled correctly
[ https://issues.apache.org/jira/browse/IMAP-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090910#comment-13090910 ] Norman Maurer commented on IMAP-292: Maybe I missed something but for me it looks like the expected output. Could you tell my why you think its incorrect ? > SEARCH is not handled correctly > -- > > Key: IMAP-292 > URL: https://issues.apache.org/jira/browse/IMAP-292 > Project: JAMES Imap > Issue Type: Bug > Components: Protocol >Affects Versions: 0.2-M1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.2 > > > SEARCH ... is not handled correctly in many cases -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1303) IMAPServer / SMTPServer / POP3Server MAY close the Channel before all messages are flushed out
IMAPServer / SMTPServer / POP3Server MAY close the Channel before all messages are flushed out -- Key: JAMES-1303 URL: https://issues.apache.org/jira/browse/JAMES-1303 Project: JAMES Server Issue Type: Bug Components: IMAPServer, POP3Server, SMTPServer Affects Versions: 3.0-beta3 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 3.0-beta4 At the moment we call Channel.close(); to close the channel. This will close the channel without make sure that all currently queued message are flushed out to the client. This can lead to some strange side effects as we may not write all data for the response out to the client before doing so. See: http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Flush-channel-before-close-td5634777.html http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Netty-behavior-when-disconnecting-a-channel-td5861795.html#a5862024 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1302) SMTPNettySession.sleep(...) is not implemented
SMTPNettySession.sleep(...) is not implemented -- Key: JAMES-1302 URL: https://issues.apache.org/jira/browse/JAMES-1302 Project: JAMES Server Issue Type: Bug Components: SMTPServer Affects Versions: 3.0-beta3 Reporter: Norman Maurer Priority: Minor Fix For: 3.0-beta4 SMTPNettySession.sleep(..) is not implemented and so not usable. At the moment it just do nothing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (PROTOCOLS-28) Use zero-file-copy if possible in AbstractSession.writeStream(...)
Use zero-file-copy if possible in AbstractSession.writeStream(...) -- Key: PROTOCOLS-28 URL: https://issues.apache.org/jira/browse/PROTOCOLS-28 Project: JAMES Protocols Issue Type: Improvement Affects Versions: 1.4.0 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 1.5 We should make use of zero-file-copy if possible in AbstractSession.writeStream(...) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (PROTOCOLS-27) AbstractSession.write(...) may fail to close the channel in some cases
[ https://issues.apache.org/jira/browse/PROTOCOLS-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved PROTOCOLS-27. Resolution: Fixed > AbstractSession.write(...) may fail to close the channel in some cases > -- > > Key: PROTOCOLS-27 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-27 > Project: JAMES Protocols > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 1.5 > > > In AbstractSession.write(...) we may fail to close the channel in some cases > because of bad timing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (PROTOCOLS-27) AbstractSession.write(...) may fail to close the channel in some cases
AbstractSession.write(...) may fail to close the channel in some cases -- Key: PROTOCOLS-27 URL: https://issues.apache.org/jira/browse/PROTOCOLS-27 Project: JAMES Protocols Issue Type: Bug Affects Versions: 1.4.0 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 1.5 In AbstractSession.write(...) we may fail to close the channel in some cases because of bad timing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1301) Use Zero-copy file transfer to transfer message content if possible
[ https://issues.apache.org/jira/browse/JAMES-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1301. -- Resolution: Fixed > Use Zero-copy file transfer to transfer message content if possible > --- > > Key: JAMES-1301 > URL: https://issues.apache.org/jira/browse/JAMES-1301 > Project: JAMES Server > Issue Type: New Feature > Components: IMAPServer, POP3Server >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > With Netty its possible to support zero-copy file transfer when a > FileInputStream was used to access the InputStream of the Message and NIO is > used. We should make use of it whenever possible as it gives a good > performance boost. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (MAILBOX-128) Add Message.getFullContent() to retrieve full message content
[ https://issues.apache.org/jira/browse/MAILBOX-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved MAILBOX-128. --- Resolution: Fixed done > Add Message.getFullContent() to retrieve full message content > - > > Key: MAILBOX-128 > URL: https://issues.apache.org/jira/browse/MAILBOX-128 > Project: James Mailbox > Issue Type: Improvement > Components: jcr mailbox, jpa mailbox, maildir mailbox, store >Affects Versions: 0.3 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.4 > > > At the moment we provide the full content of a InputStream by using a > SequenceInputStream which concat the Header InputStream and the Body > InputStream. Most times the implementation can do much better which also > allows to later cast on the returned InputStream for optimization. This is > also intersting for zero-copy file transfer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (IMAP-337) Don't wrap Content InputStream
[ https://issues.apache.org/jira/browse/IMAP-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-337. Resolution: Fixed done > Don't wrap Content InputStream > -- > > Key: IMAP-337 > URL: https://issues.apache.org/jira/browse/IMAP-337 > Project: JAMES Imap > Issue Type: Improvement > Components: Processor >Affects Versions: 0.2.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.3 > > > At the moment we wrap the InputStream of Content in a BoundedInputStream. > This is not necessary and also make it impossible todo any futher > optimization later when accessing the InputStream as it is not of the type as > it was before. This becomes a pain when we want to use zero-copy file > transfer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1301) Use Zero-copy file transfer to transfer message content if possible
Use Zero-copy file transfer to transfer message content if possible --- Key: JAMES-1301 URL: https://issues.apache.org/jira/browse/JAMES-1301 Project: JAMES Server Issue Type: New Feature Components: IMAPServer, POP3Server Affects Versions: 3.0-beta3 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 3.0-beta4 With Netty its possible to support zero-copy file transfer when a FileInputStream was used to access the InputStream of the Message and NIO is used. We should make use of it whenever possible as it gives a good performance boost. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (MAILBOX-128) Add Message.getFullContent() to retrieve full message content
Add Message.getFullContent() to retrieve full message content - Key: MAILBOX-128 URL: https://issues.apache.org/jira/browse/MAILBOX-128 Project: James Mailbox Issue Type: Improvement Components: jcr mailbox, jpa mailbox, maildir mailbox, store Affects Versions: 0.3 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.4 At the moment we provide the full content of a InputStream by using a SequenceInputStream which concat the Header InputStream and the Body InputStream. Most times the implementation can do much better which also allows to later cast on the returned InputStream for optimization. This is also intersting for zero-copy file transfer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (IMAP-337) Don't wrap Content InputStream
Don't wrap Content InputStream -- Key: IMAP-337 URL: https://issues.apache.org/jira/browse/IMAP-337 Project: JAMES Imap Issue Type: Improvement Components: Processor Affects Versions: 0.2.1 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.3 At the moment we wrap the InputStream of Content in a BoundedInputStream. This is not necessary and also make it impossible todo any futher optimization later when accessing the InputStream as it is not of the type as it was before. This becomes a pain when we want to use zero-copy file transfer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (MAILBOX-118) MaildirStore not setup correctly
[ https://issues.apache.org/jira/browse/MAILBOX-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated MAILBOX-118: -- Summary: MaildirStore not setup correctly (was: MaildirStore) > MaildirStore not setup correctly > > > Key: MAILBOX-118 > URL: https://issues.apache.org/jira/browse/MAILBOX-118 > Project: James Mailbox > Issue Type: Bug > Components: spring >Affects Versions: 0.4 >Reporter: Norman Maurer > Fix For: 0.4 > > > The MaildirStore gets constructed via "file://var/store/maildir/" which does > not work. This will create the following directory structure in the current > directory: > ./file:/var/store/maildir > See: > http://svn.apache.org/viewvc/james/mailbox/trunk/spring/src/main/resources/META-INF/org/apache/james/spring-mailbox-maildir.xml?view=markup > > We should maybe better allow to override this via the > PropertyPlaceHolderConfigurer to make it more usable: > http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html > Also we need to add %d/%u or %u to the path otherwise it will just create the > inbox directly in the "maildir" folder -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (MAILBOX-118) MaildirStore
MaildirStore Key: MAILBOX-118 URL: https://issues.apache.org/jira/browse/MAILBOX-118 Project: James Mailbox Issue Type: Bug Components: spring Affects Versions: 0.4 Reporter: Norman Maurer Fix For: 0.4 The MaildirStore gets constructed via "file://var/store/maildir/" which does not work. This will create the following directory structure in the current directory: ./file:/var/store/maildir See: http://svn.apache.org/viewvc/james/mailbox/trunk/spring/src/main/resources/META-INF/org/apache/james/spring-mailbox-maildir.xml?view=markup We should maybe better allow to override this via the PropertyPlaceHolderConfigurer to make it more usable: http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/beans/factory/config/PropertyPlaceholderConfigurer.html Also we need to add %d/%u or %u to the path otherwise it will just create the inbox directly in the "maildir" folder -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (IMAP-336) Use static fields where possible for CAPABILITIES
[ https://issues.apache.org/jira/browse/IMAP-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-336. Resolution: Fixed > Use static fields where possible for CAPABILITIES > - > > Key: IMAP-336 > URL: https://issues.apache.org/jira/browse/IMAP-336 > Project: JAMES Imap > Issue Type: Improvement > Components: Protocol >Affects Versions: 0.2.1 >Reporter: Norman Maurer >Assignee: Norman Maurer >Priority: Minor > Fix For: 0.3 > > > Most times we return the same CAPABILITES everytime to the client. In the > code we often create a new ArrayList for this on every response. This is not > needed as these will never change. So we should use a unmodifiable static > List and just return it -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1300) Deactive IMAP IDLE keep-alives
Deactive IMAP IDLE keep-alives -- Key: JAMES-1300 URL: https://issues.apache.org/jira/browse/JAMES-1300 Project: JAMES Server Issue Type: Improvement Components: IMAPServer Affects Versions: 3.0-beta3 Reporter: Norman Maurer Assignee: Norman Maurer Priority: Minor Fix For: 3.0-beta4 The IdleProcessor sends IDLE keep-alives every x seconds by default. As we send Keep alives on all commands we can disable these IDLE keep-alives to save some resources / threads. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (IMAP-336) Use static fields where possible for CAPABILITIES
Use static fields where possible for CAPABILITIES - Key: IMAP-336 URL: https://issues.apache.org/jira/browse/IMAP-336 Project: JAMES Imap Issue Type: Improvement Components: Protocol Affects Versions: 0.2.1 Reporter: Norman Maurer Assignee: Norman Maurer Priority: Minor Fix For: 0.3 Most times we return the same CAPABILITES everytime to the client. In the code we often create a new ArrayList for this on every response. This is not needed as these will never change. So we should use a unmodifiable static List and just return it -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (IMAP-335) Review synchronization / locking
Review synchronization / locking Key: IMAP-335 URL: https://issues.apache.org/jira/browse/IMAP-335 Project: JAMES Imap Issue Type: Improvement Affects Versions: 0.2.1 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.3 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (IMAP-334) Only use one Thread for Idle keep-alives
Only use one Thread for Idle keep-alives Key: IMAP-334 URL: https://issues.apache.org/jira/browse/IMAP-334 Project: JAMES Imap Issue Type: Improvement Components: Protocol Reporter: Norman Maurer Assignee: Norman Maurer Priority: Minor At the moment we schedule one thread per connection for keep alives. We should better use a pool of x threads for the keep alives so we don't have the one thread per connection overhead all the time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (MAILBOX-117) Review synchronization / locking
Review synchronization / locking Key: MAILBOX-117 URL: https://issues.apache.org/jira/browse/MAILBOX-117 Project: James Mailbox Issue Type: Improvement Affects Versions: 0.3 Reporter: Norman Maurer Assignee: Norman Maurer Priority: Minor Fix For: 0.4 We should review the current usage of synchronization / locking. We often use synchronization even if the implementations should not be used in a multi-threaded manner -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (MAILBOX-116) Lazy load and populate the MimeDescriptor
[ https://issues.apache.org/jira/browse/MAILBOX-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved MAILBOX-116. --- Resolution: Fixed done! > Lazy load and populate the MimeDescriptor > - > > Key: MAILBOX-116 > URL: https://issues.apache.org/jira/browse/MAILBOX-116 > Project: James Mailbox > Issue Type: Improvement > Components: store >Affects Versions: 0.3 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.4 > > > At the moment we pre-load the MimeDescriptor when create the MessageResult > even if we maybe don't access it later. Loading the MimeDescriptor can be > really heavy-weight and also very slow depending on the underlying mailbox > implementation (it may need to parse the whole message for it). We also > should make sure to re-used previous parsed header instances as at the moment > we re-parse the raw header when generating the MimeDescriptor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (IMAP-333) FETCH 1 BODY[...] should not create a MimeDescriptorStructure
[ https://issues.apache.org/jira/browse/IMAP-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-333. Resolution: Fixed > FETCH 1 BODY[...] should not create a MimeDescriptorStructure > - > > Key: IMAP-333 > URL: https://issues.apache.org/jira/browse/IMAP-333 > Project: JAMES Imap > Issue Type: Improvement > Components: Protocol >Affects Versions: 0.2.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.3 > > > We don't need to generate a MimeDescriptorStructure if a client issue the > following commands: > FETCH 1 BODY[] > FETCH 1 BODY.PEEK[] > The generation of such a MimeDescriptorStructure can be really heavy weight > as it may need to parse the whole message content. So its better to skip the > generation of it whenever possible. > Its only needed for the following commands: > FETCH 1 BODY > FETCH 1 BODYSTRUCTURE -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (IMAP-333) FETCH 1 BODY[...] should not create a MimeDescriptorStructure
[ https://issues.apache.org/jira/browse/IMAP-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated IMAP-333: --- Description: We don't need to generate a MimeDescriptorStructure if a client issue the following commands: FETCH 1 BODY[] FETCH 1 BODY.PEEK[] The generation of such a MimeDescriptorStructure can be really heavy weight as it may need to parse the whole message content. So its better to skip the generation of it whenever possible. Its only needed for the following commands: FETCH 1 BODY FETCH 1 BODYSTRUCTURE was: We don't need to generate a MimeDescriptorStructure if a client issue the following command: FETCH 1 BODY[] The generation of such a MimeDescriptorStructure can be really heavy weight as it may need to parse the whole message content. So its better to skip the generation of it whenever possible. Its only needed for the following commands: FETCH 1 BODY FETCH 1 BODYSTRUCTURE > FETCH 1 BODY[...] should not create a MimeDescriptorStructure > - > > Key: IMAP-333 > URL: https://issues.apache.org/jira/browse/IMAP-333 > Project: JAMES Imap > Issue Type: Improvement > Components: Protocol >Affects Versions: 0.2.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.3 > > > We don't need to generate a MimeDescriptorStructure if a client issue the > following commands: > FETCH 1 BODY[] > FETCH 1 BODY.PEEK[] > The generation of such a MimeDescriptorStructure can be really heavy weight > as it may need to parse the whole message content. So its better to skip the > generation of it whenever possible. > Its only needed for the following commands: > FETCH 1 BODY > FETCH 1 BODYSTRUCTURE -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (MAILBOX-116) Lazy load and populate the MimeDescriptor
Lazy load and populate the MimeDescriptor - Key: MAILBOX-116 URL: https://issues.apache.org/jira/browse/MAILBOX-116 Project: James Mailbox Issue Type: Improvement Components: store Affects Versions: 0.3 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.4 At the moment we pre-load the MimeDescriptor when create the MessageResult even if we maybe don't access it later. Loading the MimeDescriptor can be really heavy-weight and also very slow depending on the underlying mailbox implementation (it may need to parse the whole message for it). We also should make sure to re-used previous parsed header instances as at the moment we re-parse the raw header when generating the MimeDescriptor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (IMAP-333) FETCH 1 BODY[...] should not create a MimeDescriptorStructure
FETCH 1 BODY[...] should not create a MimeDescriptorStructure - Key: IMAP-333 URL: https://issues.apache.org/jira/browse/IMAP-333 Project: JAMES Imap Issue Type: Improvement Components: Protocol Affects Versions: 0.2.1 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.3 We don't need to generate a MimeDescriptorStructure if a client issue the following command: FETCH 1 BODY[] The generation of such a MimeDescriptorStructure can be really heavy weight as it may need to parse the whole message content. So its better to skip the generation of it whenever possible. Its only needed for the following commands: FETCH 1 BODY FETCH 1 BODYSTRUCTURE -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (IMAP-332) Use raw message header in FETCH if possible to build the response
[ https://issues.apache.org/jira/browse/IMAP-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-332. Resolution: Fixed > Use raw message header in FETCH if possible to build the response > - > > Key: IMAP-332 > URL: https://issues.apache.org/jira/browse/IMAP-332 > Project: JAMES Imap > Issue Type: Improvement > Components: Protocol >Affects Versions: 0.2.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.3 > > > At the moment we use the parsed message header to build the FETCH response > even if the raw header would be enough. Using the raw header would allow us > to not parse it at all and so give some performance boost. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (MAILBOX-115) Allow to acces raw message header without parsing it
[ https://issues.apache.org/jira/browse/MAILBOX-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved MAILBOX-115. --- Resolution: Fixed > Allow to acces raw message header without parsing it > > > Key: MAILBOX-115 > URL: https://issues.apache.org/jira/browse/MAILBOX-115 > Project: James Mailbox > Issue Type: Improvement > Components: api, store >Affects Versions: 0.3 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.4 > > > At the moment we parse the message header in seperate fields even if we would > only get the raw header content as InputStream. We should allow to access the > raw content without the need of parsing for such cases. This can speed up > things a lot when requesting the header of many messages. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
