Re: NoSQL backend for James
2011/10/10 Pepijn de Vos : > Thanks a lot. > > On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote: > >> Have patience. You will need it if you wish to complete something. >> Patience and perseverance or else you'll be just another one who >> tried. > > I don't expect to have it finished by the end of the week, but if I'm still > completely clueless by then, it's just not worth the effort. > I don't have the ambition to become a James commiter or even a Java dev, I > just thought it would be nice to use CouchDB for my application. > Somewhere is a point where pragmatism beats learning. There isn't any > technical reason why I can't use JPA. >> >>> Can I just copy an existing one and rename stuff? In other words, how are >>> the modules glued into the whole? How does the server know which class to >>> load? It's not in the pom.xml, afaict. >> >> Not sure what you mean by that. It uses dependency injection provided >> by Spring framework (and soon Guice) to inject object references into >> other objects at runtime. > > Ah, dependency injection. *googles* So just the fact that I implement the > interface is enough to @autowire it into James? Yes. The wonders of DI. >> >>> The sample config is gone btw: >>> http://james.apache.org/server/3/config-mailbox.html >>> Do I inherit tests as well? I would imagine that a lot of tests are common >>> to all mailbox implementations. >> >> I think this is because the configuration changed and now it's spring >> based, and more modular. I see you are very ambitious but I sense you >> have a lot of catching up. James is complex so give it time, if you >> expect too much from yourself and fail you will probably be too >> disappointed. > Yea, I read a Java book long ago, never did any big projects with it. >> >> Make a public repo, commit something and ask if you get stuck. I will >> try to help when/if I can. I suggest you start with simple >> implementation that passes some unit tests. > > So If I take any mailbox impl, put it in a separate repo, will it work? All > sorts of things refer to the parent pom. I'll put something on github once I > figure it out. I think it'll work out once I get to the point where I can > write some code. Maven download all it's dependencies. Just declare the group and the artifact and make sure the repository has those (it will complain if it doesn't find them). If not, find a maven repo that has them and put it in your pom. >> >> See for example the unit tests I did for Mailbox interface in HBase >> implementation: >> http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java > What I mean with inheriting tests is that these all look very generic. They > look like they could test any mailbox implementation. Up to some point, they should be generic because they implement an API. Unit testing is suposed to test methods individually so they should be quite simple. They have the purpose to keep you from writing methods that accept or return values out of the accepted range. They also keep you from introducing bugs in your implementation. Changes in your method body will affect your tests. If they fail, something is wrong. either your method, or your test. Having good tests is very important. Unit tests should especially test for boundary values (null, negatives, 0, etc). -- Ioan Eugen Stan http://ieugen.blogspot.com/ - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: NoSQL backend for James
Thanks a lot. On Oct 10, 2011, at 8:24 PM, Ioan Eugen Stan wrote: > Have patience. You will need it if you wish to complete something. > Patience and perseverance or else you'll be just another one who > tried. I don't expect to have it finished by the end of the week, but if I'm still completely clueless by then, it's just not worth the effort. I don't have the ambition to become a James commiter or even a Java dev, I just thought it would be nice to use CouchDB for my application. Somewhere is a point where pragmatism beats learning. There isn't any technical reason why I can't use JPA. > >> Can I just copy an existing one and rename stuff? In other words, how are >> the modules glued into the whole? How does the server know which class to >> load? It's not in the pom.xml, afaict. > > Not sure what you mean by that. It uses dependency injection provided > by Spring framework (and soon Guice) to inject object references into > other objects at runtime. Ah, dependency injection. *googles* So just the fact that I implement the interface is enough to @autowire it into James? > >> The sample config is gone btw: >> http://james.apache.org/server/3/config-mailbox.html >> Do I inherit tests as well? I would imagine that a lot of tests are common >> to all mailbox implementations. > > I think this is because the configuration changed and now it's spring > based, and more modular. I see you are very ambitious but I sense you > have a lot of catching up. James is complex so give it time, if you > expect too much from yourself and fail you will probably be too > disappointed. Yea, I read a Java book long ago, never did any big projects with it. > > Make a public repo, commit something and ask if you get stuck. I will > try to help when/if I can. I suggest you start with simple > implementation that passes some unit tests. So If I take any mailbox impl, put it in a separate repo, will it work? All sorts of things refer to the parent pom. I'll put something on github once I figure it out. I think it'll work out once I get to the point where I can write some code. > > See for example the unit tests I did for Mailbox interface in HBase > implementation: > http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java What I mean with inheriting tests is that these all look very generic. They look like they could test any mailbox implementation. Pepijn > > > -- > Ioan Eugen Stan > http://ieugen.blogspot.com/ > > - > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (MAILBOX-151) AbstractDelegatingMailboxListeners should release locks faster
AbstractDelegatingMailboxListeners should release locks faster -- Key: MAILBOX-151 URL: https://issues.apache.org/jira/browse/MAILBOX-151 Project: James Mailbox Issue Type: Improvement Components: store Affects Versions: 0.3 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.4 In AbstractDelegatingMailboxListeners.event(...) we do a very bad job in releasing the locks in a timely manner, as we execute the whole MailboxListener.event(...) calls in the synchronized block. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
svn commit: r1181173 [2/2] - in /james/imap/trunk: api/src/main/java/org/apache/james/imap/api/message/response/ api/src/main/java/org/apache/james/imap/api/process/ message/src/main/java/org/apache/j
Modified:
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/CreateProcessor.java
URL:
http://svn.apache.org/viewvc/james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/CreateProcessor.java?rev=1181173&r1=1181172&r2=1181173&view=diff
==
---
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/CreateProcessor.java
(original)
+++
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/CreateProcessor.java
Mon Oct 10 19:46:43 2011
@@ -37,12 +37,9 @@ public class CreateProcessor extends Abs
super(CreateRequest.class, next, mailboxManager, factory);
}
-/*
- * (non-Javadoc)
- *
+/**
* @see
- * org.apache.james.imap.processor.AbstractMailboxProcessor#doProcess(org
- * .apache.james.imap.api.message.request.ImapRequest,
+ *
org.apache.james.imap.processor.AbstractMailboxProcessor#doProcess(org.apache.james.imap.api.message.request.ImapRequest,
* org.apache.james.imap.api.process.ImapSession, java.lang.String,
* org.apache.james.imap.api.ImapCommand,
* org.apache.james.imap.api.process.ImapProcessor.Responder)
Modified:
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/DeleteProcessor.java
URL:
http://svn.apache.org/viewvc/james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/DeleteProcessor.java?rev=1181173&r1=1181172&r2=1181173&view=diff
==
---
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/DeleteProcessor.java
(original)
+++
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/DeleteProcessor.java
Mon Oct 10 19:46:43 2011
@@ -38,12 +38,9 @@ public class DeleteProcessor extends Abs
super(DeleteRequest.class, next, mailboxManager, factory);
}
-/*
- * (non-Javadoc)
- *
+/**
* @see
- * org.apache.james.imap.processor.AbstractMailboxProcessor#doProcess(org
- * .apache.james.imap.api.message.request.ImapRequest,
+ *
org.apache.james.imap.processor.AbstractMailboxProcessor#doProcess(org.apache.james.imap.api.message.request.ImapRequest,
* org.apache.james.imap.api.process.ImapSession, java.lang.String,
* org.apache.james.imap.api.ImapCommand,
* org.apache.james.imap.api.process.ImapProcessor.Responder)
Modified:
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/EnableProcessor.java
URL:
http://svn.apache.org/viewvc/james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/EnableProcessor.java?rev=1181173&r1=1181172&r2=1181173&view=diff
==
---
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/EnableProcessor.java
(original)
+++
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/EnableProcessor.java
Mon Oct 10 19:46:43 2011
@@ -57,9 +57,11 @@ public class EnableProcessor extends Abs
}
-/*
- * (non-Javadoc)
- * @see
org.apache.james.imap.processor.AbstractMailboxProcessor#doProcess(org.apache.james.imap.api.message.request.ImapRequest,
org.apache.james.imap.api.process.ImapSession, java.lang.String,
org.apache.james.imap.api.ImapCommand,
org.apache.james.imap.api.process.ImapProcessor.Responder)
+/**
+ * @see org.apache.james.imap.processor.AbstractMailboxProcessor
+ * #doProcess(org.apache.james.imap.api.message.request.ImapRequest,
+ * org.apache.james.imap.api.process.ImapSession, java.lang.String,
+ * org.apache.james.imap.api.ImapCommand,
org.apache.james.imap.api.process.ImapProcessor.Responder)
*/
protected void doProcess(EnableRequest request, ImapSession session,
String tag, ImapCommand command, Responder responder) {
try {
@@ -123,11 +125,9 @@ public class EnableProcessor extends Abs
return caps;
}
-/*
- * (non-Javadoc)
- *
- * @see org.apache.james.imap.processor.CapabilityImplementingProcessor#
- *
getImplementedCapabilities(org.apache.james.imap.api.process.ImapSession)
+/**
+ * @see org.apache.james.imap.processor.CapabilityImplementingProcessor
+ *
#getImplementedCapabilities(org.apache.james.imap.api.process.ImapSession)
*/
public List getImplementedCapabilities(ImapSession session) {
return CAPS;
Modified:
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/ExpungeProcessor.java
URL:
http://svn.apache.org/viewvc/james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/ExpungeProcessor.java?rev=1181173&r1=1181172&r2=1181173&view=diff
==
---
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/ExpungeProcess
svn commit: r1181144 - /james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/base/SelectedMailboxImpl.java
Author: norman
Date: Mon Oct 10 19:13:46 2011
New Revision: 1181144
URL: http://svn.apache.org/viewvc?rev=1181144&view=rev
Log:
Don't lock mailbox longer then necessary...
Modified:
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/base/SelectedMailboxImpl.java
Modified:
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/base/SelectedMailboxImpl.java
URL:
http://svn.apache.org/viewvc/james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/base/SelectedMailboxImpl.java?rev=1181144&r1=1181143&r2=1181144&view=diff
==
---
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/base/SelectedMailboxImpl.java
(original)
+++
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/base/SelectedMailboxImpl.java
Mon Oct 10 19:13:46 2011
@@ -78,7 +78,8 @@ public class SelectedMailboxImpl impleme
private boolean isDeletedByOtherSession = false;
private boolean sizeChanged = false;
private boolean silentFlagChanges = false;
-private Flags applicableFlags;
+private final Flags applicableFlags = new Flags(FLAGS);
+
private boolean applicableFlagsChanged;
private final SortedMap msnToUid =new TreeMap();;
@@ -101,23 +102,24 @@ public class SelectedMailboxImpl impleme
}
-private synchronized void init() throws MailboxException {
+private void init() throws MailboxException {
MailboxSession mailboxSession =
ImapSessionUtils.getMailboxSession(session);
mailboxManager.addListener(path, this, mailboxSession);
MessageResultIterator messages = mailboxManager.getMailbox(path,
mailboxSession).getMessages(MessageRange.all(), FetchGroupImpl.MINIMAL,
mailboxSession);
-Flags applicableFlags = new Flags(FLAGS);
-while(messages.hasNext()) {
-MessageResult mr = messages.next();
-applicableFlags.add(mr.getFlags());
-add(mr.getUid());
+synchronized (this) {
+while(messages.hasNext()) {
+MessageResult mr = messages.next();
+applicableFlags.add(mr.getFlags());
+add(mr.getUid());
+}
+
+
+// \RECENT is not a applicable flag in imap so remove it from the
list
+applicableFlags.remove(Flags.Flag.RECENT);
}
-
-
-// \RECENT is not a applicable flag in imap so remove it from the list
-applicableFlags.remove(Flags.Flag.RECENT);
-this.applicableFlags = applicableFlags;
+
}
private void add(int msn, long uid) {
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
svn commit: r1181122 - /james/imap/trunk/pom.xml
Author: felixk
Date: Mon Oct 10 18:36:30 2011
New Revision: 1181122
URL: http://svn.apache.org/viewvc?rev=1181122&view=rev
Log:
Add javadoc generation for 'normal' site generation
Modified:
james/imap/trunk/pom.xml
Modified: james/imap/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/james/imap/trunk/pom.xml?rev=1181122&r1=1181121&r2=1181122&view=diff
==
--- james/imap/trunk/pom.xml (original)
+++ james/imap/trunk/pom.xml Mon Oct 10 18:36:30 2011
@@ -316,7 +316,7 @@
WARNING
-1.5
+${target.jdk}
@@ -362,6 +362,41 @@
+
+org.apache.maven.plugins
+maven-javadoc-plugin
+
+
+site
+
+ aggregate
+
+
+
+
+ 256m
+ 1g
+ true
+
+
+ note
+ a
+ NOTE
+
+
+ todo
+ a
+ TODO
+
+
+ warning
+ a
+ WARNING
+
+
+ ${target.jdk}
+
+
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (PROTOCOLS-41) Don't try log hostname on connect/disconnect
[ https://issues.apache.org/jira/browse/PROTOCOLS-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved PROTOCOLS-41. Resolution: Fixed done > Don't try log hostname on connect/disconnect > > > Key: PROTOCOLS-41 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-41 > Project: JAMES Protocols > Issue Type: Improvement >Affects Versions: 1.6-beta1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 1.6-beta2 > > > At the moment we log the ipaddress and hostname on each connect/disconnect. > This may need a reverse dns lookup and so keeps the io-thread busy. We should > just lok the ipaddress as this is most times what people care about. This > will speed up things -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
svn commit: r1181115 - /james/protocols/trunk/impl/src/main/java/org/apache/james/protocols/impl/BasicChannelUpstreamHandler.java
Author: norman
Date: Mon Oct 10 18:28:43 2011
New Revision: 1181115
URL: http://svn.apache.org/viewvc?rev=1181115&view=rev
Log:
Don't try log hostname on connect/disconnect. See PROTOCOLS-41
Modified:
james/protocols/trunk/impl/src/main/java/org/apache/james/protocols/impl/BasicChannelUpstreamHandler.java
Modified:
james/protocols/trunk/impl/src/main/java/org/apache/james/protocols/impl/BasicChannelUpstreamHandler.java
URL:
http://svn.apache.org/viewvc/james/protocols/trunk/impl/src/main/java/org/apache/james/protocols/impl/BasicChannelUpstreamHandler.java?rev=1181115&r1=1181114&r2=1181115&view=diff
==
---
james/protocols/trunk/impl/src/main/java/org/apache/james/protocols/impl/BasicChannelUpstreamHandler.java
(original)
+++
james/protocols/trunk/impl/src/main/java/org/apache/james/protocols/impl/BasicChannelUpstreamHandler.java
Mon Oct 10 18:28:43 2011
@@ -89,7 +89,7 @@ public class BasicChannelUpstreamHandler
List connectHandlers =
chain.getHandlers(ConnectHandler.class);
List resultHandlers =
chain.getHandlers(ProtocolHandlerResultHandler.class);
ProtocolSession session = (ProtocolSession) ctx.getAttachment();
-session.getLogger().info("Connection established from " +
session.getRemoteHost() + " (" + session.getRemoteIPAddress()+ ")");
+session.getLogger().info("Connection established from " +
session.getRemoteIPAddress());
if (connectHandlers != null) {
for (int i = 0; i < connectHandlers.size(); i++) {
ConnectHandler cHandler = connectHandlers.get(i);
@@ -183,7 +183,7 @@ public class BasicChannelUpstreamHandler
public void channelClosed(ChannelHandlerContext ctx, ChannelStateEvent e)
throws Exception {
ProtocolSession session = (ProtocolSession) ctx.getAttachment();
if (session != null) {
-session.getLogger().info("Connection closed for " +
session.getRemoteHost() + " (" + session.getRemoteIPAddress()+ ")");
+session.getLogger().info("Connection closed for " +
session.getRemoteIPAddress());
}
cleanup(ctx);
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (PROTOCOLS-41) Don't try log hostname on connect/disconnect
Don't try log hostname on connect/disconnect Key: PROTOCOLS-41 URL: https://issues.apache.org/jira/browse/PROTOCOLS-41 Project: JAMES Protocols Issue Type: Improvement Affects Versions: 1.6-beta1 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 1.6-beta2 At the moment we log the ipaddress and hostname on each connect/disconnect. This may need a reverse dns lookup and so keeps the io-thread busy. We should just lok the ipaddress as this is most times what people care about. This will speed up things -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
Re: NoSQL backend for James
2011/10/10 Pepijn de Vos : > Thanks, helpful :) More questions! > > What is the modification sequence? (ModSeqProvider) This? > http://tools.ietf.org/html/rfc4551 It's a way to see if the mailbox has been modified (flags changed, etc.). > I guess the UID is just that of a message? It's a number that uniquely identifies a message in a mailbox. the RFC states it is 32 bits long. > Do both need to be an increasing long? ( > http://wiki.apache.org/couchdb/HttpGetUuids ) > > I'm soon going to start my implementation. I will force myself to have > *something* by the end of the week, or I'll just give up and use JPA. Have patience. You will need it if you wish to complete something. Patience and perseverance or else you'll be just another one who tried. > Can I just copy an existing one and rename stuff? In other words, how are the > modules glued into the whole? How does the server know which class to load? > It's not in the pom.xml, afaict. Not sure what you mean by that. It uses dependency injection provided by Spring framework (and soon Guice) to inject object references into other objects at runtime. > The sample config is gone btw: > http://james.apache.org/server/3/config-mailbox.html > Do I inherit tests as well? I would imagine that a lot of tests are common to > all mailbox implementations. I think this is because the configuration changed and now it's spring based, and more modular. I see you are very ambitious but I sense you have a lot of catching up. James is complex so give it time, if you expect too much from yourself and fail you will probably be too disappointed. Make a public repo, commit something and ask if you get stuck. I will try to help when/if I can. I suggest you start with simple implementation that passes some unit tests. See for example the unit tests I did for Mailbox interface in HBase implementation: http://svn.apache.org/repos/asf/james/mailbox/trunk/hbase/src/test/java/org/apache/james/mailbox/hbase/mail/model/HBaseMailboxTest.java -- Ioan Eugen Stan http://ieugen.blogspot.com/ - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (PROTOCOLS-40) Use geronimo as a dependency for javamail instead of oracle javamail so that we don't need "repositories" entry in pom.
[ https://issues.apache.org/jira/browse/PROTOCOLS-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer updated PROTOCOLS-40: --- Fix Version/s: (was: 1.6-beta1) 1.6-beta2 > Use geronimo as a dependency for javamail instead of oracle javamail so that > we don't need "repositories" entry in pom. > --- > > Key: PROTOCOLS-40 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-40 > Project: JAMES Protocols > Issue Type: Task >Affects Versions: 1.5 >Reporter: Stefano Bagnara >Assignee: Norman Maurer > Fix For: 1.6-beta2 > > > This is a library project so we don't need to depend on an actual > implementation (like we do, instead, in james server), but only on the api, > and we can use api from geronimo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-347) FetchProcessor should skip messages that can't get parsed
FetchProcessor should skip messages that can't get parsed - Key: IMAP-347 URL: https://issues.apache.org/jira/browse/IMAP-347 Project: JAMES Imap Issue Type: Bug Components: Processor Affects Versions: 0.2.1 Reporter: Norman Maurer Assignee: Norman Maurer Fix For: 0.3 In FetchProcessor we build the FetchResponse per requested message. This may for whatever reason. In this case we error out and return a BAD response to the client. This is not a very good way to handle it. We should better skip the message and log it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-347) FetchProcessor should skip messages that can't get parsed
[ https://issues.apache.org/jira/browse/IMAP-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-347. Resolution: Fixed done > FetchProcessor should skip messages that can't get parsed > - > > Key: IMAP-347 > URL: https://issues.apache.org/jira/browse/IMAP-347 > Project: JAMES Imap > Issue Type: Bug > Components: Processor >Affects Versions: 0.2.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.3 > > > In FetchProcessor we build the FetchResponse per requested message. This may > for whatever reason. In this case we error out and return a BAD response to > the client. This is not a very good way to handle it. We should better skip > the message and log it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
svn commit: r1181108 - /james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/fetch/FetchProcessor.java
Author: norman
Date: Mon Oct 10 18:11:39 2011
New Revision: 1181108
URL: http://svn.apache.org/viewvc?rev=1181108&view=rev
Log:
FetchProcessor should skip messages that can't get parsed. See IMAP-347
Modified:
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/fetch/FetchProcessor.java
Modified:
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/fetch/FetchProcessor.java
URL:
http://svn.apache.org/viewvc/james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/fetch/FetchProcessor.java?rev=1181108&r1=1181107&r2=1181108&view=diff
==
---
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/fetch/FetchProcessor.java
(original)
+++
james/imap/trunk/processor/src/main/java/org/apache/james/imap/processor/fetch/FetchProcessor.java
Mon Oct 10 18:11:39 2011
@@ -172,6 +172,14 @@ public class FetchProcessor extends Abst
if (session.getLog().isDebugEnabled()) {
session.getLog().debug("Unable to find message with
uid " + result.getUid(), e);
}
+} catch (MailboxException e) {
+// we can't for whatever reason find parse all requested
parts of the message. This may because it was deleted while try to access the
parts.
+// So we just skip it
+//
+// See IMAP-347
+if (session.getLog().isDebugEnabled()) {
+session.getLog().debug("Unable to fetch message with
uid " + result.getUid() + ", so skip it", e);
+}
}
}
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
svn commit: r1181103 - /james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/netty/ImapChannelUpstreamHandler.java
Author: norman
Date: Mon Oct 10 18:04:47 2011
New Revision: 1181103
URL: http://svn.apache.org/viewvc?rev=1181103&view=rev
Log:
Don't log the hostname as it needs a reverse lookup and so slow down things.
See JAMES-1329
Modified:
james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/netty/ImapChannelUpstreamHandler.java
Modified:
james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/netty/ImapChannelUpstreamHandler.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/netty/ImapChannelUpstreamHandler.java?rev=1181103&r1=1181102&r2=1181103&view=diff
==
---
james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/netty/ImapChannelUpstreamHandler.java
(original)
+++
james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/netty/ImapChannelUpstreamHandler.java
Mon Oct 10 18:04:47 2011
@@ -98,7 +98,7 @@ public class ImapChannelUpstreamHandler
@Override
public void channelClosed(ChannelHandlerContext ctx, ChannelStateEvent e)
throws Exception {
InetSocketAddress address = (InetSocketAddress)
ctx.getChannel().getRemoteAddress();
-getLogger(ctx.getChannel()).info("Connection closed for " +
address.getHostName() + " (" + address.getAddress().getHostAddress() + ")");
+getLogger(ctx.getChannel()).info("Connection closed for " +
address.getAddress().getHostAddress());
// remove the stored attribute for the channel to free up resources
// See JAMES-1195
@@ -112,7 +112,7 @@ public class ImapChannelUpstreamHandler
@Override
public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent
e) throws Exception {
InetSocketAddress address = (InetSocketAddress)
ctx.getChannel().getRemoteAddress();
-getLogger(ctx.getChannel()).info("Connection established from " +
address.getHostName() + " (" + address.getAddress().getHostAddress() + ")");
+getLogger(ctx.getChannel()).info("Connection established from " +
address.getAddress().getHostAddress());
ImapResponseComposer response = new ImapResponseComposerImpl(new
ChannelImapResponseWriter(ctx.getChannel()));
ctx.setAttachment(response);
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-1329) ImapChannelUpstreamHandler should not do a reverse lookup for logging
[ https://issues.apache.org/jira/browse/JAMES-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved JAMES-1329. -- Resolution: Fixed Assignee: Norman Maurer fixed > ImapChannelUpstreamHandler should not do a reverse lookup for logging > - > > Key: JAMES-1329 > URL: https://issues.apache.org/jira/browse/JAMES-1329 > Project: JAMES Server > Issue Type: Improvement > Components: IMAPServer >Affects Versions: 3.0-beta3 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta4 > > > In ImapChannelUpstreamHandler we log the ipaddress and the hostname for each > connect/disconnect. This is a waste of resources as for the hostname java > needs todo a reverse lookup which unnecessary can block the boss/worker > thread of netty. > To speed up things we should only log the ipaddress. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-1329) ImapChannelUpstreamHandler should not do a reverse lookup for logging
ImapChannelUpstreamHandler should not do a reverse lookup for logging - Key: JAMES-1329 URL: https://issues.apache.org/jira/browse/JAMES-1329 Project: JAMES Server Issue Type: Improvement Components: IMAPServer Affects Versions: 3.0-beta3 Reporter: Norman Maurer Fix For: 3.0-beta4 In ImapChannelUpstreamHandler we log the ipaddress and the hostname for each connect/disconnect. This is a waste of resources as for the hostname java needs todo a reverse lookup which unnecessary can block the boss/worker thread of netty. To speed up things we should only log the ipaddress. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
Re: NoSQL backend for James
Thanks, helpful :) More questions! What is the modification sequence? (ModSeqProvider) This? http://tools.ietf.org/html/rfc4551 I guess the UID is just that of a message? Do both need to be an increasing long? ( http://wiki.apache.org/couchdb/HttpGetUuids ) I'm soon going to start my implementation. I will force myself to have *something* by the end of the week, or I'll just give up and use JPA. Can I just copy an existing one and rename stuff? In other words, how are the modules glued into the whole? How does the server know which class to load? It's not in the pom.xml, afaict. The sample config is gone btw: http://james.apache.org/server/3/config-mailbox.html Do I inherit tests as well? I would imagine that a lot of tests are common to all mailbox implementations. Pepijn On Oct 4, 2011, at 11:49 AM, Ioan Eugen Stan wrote: > 2011/10/4 Pepijn de Vos : >> Another piece of the puzzle. HBase and JPA use less of the classes from the >> Store API. Therefore they also extend the managers to provide their custom >> classes. I'm still not sure why they do that, instead of using for example >> SimpleMessage. >> >> I found a Couch library that claims to be a lot like JPA. I would study the >> JPA impl, but maybe there is a good reason to look at HBase instead? > > There are a couple of things that a mailbox implementation must do, > but it's main job is to store messages in mailboxes and provide a way > for the user to retrieve them back. > > The main "components" that you must be aware in a mailbox implementation are: > > 1. Mailboxes - they are similar to file-system folders and are used to > group together related messages. > 2. Messages - must belong to a mailbox (default is INBOX) and have > some interesting properties (unique UIDs, they are immutable, they > have properties and flags). Much of this information is defined in > specific RFC's (Mail RFC, IMAP RFC, MIME RFC). > 3. Subscription - the best way I can explain this is that you can > subscribe to mailboxes (other than you own - like news, etc; See IMAP > RFC). When you connect to receive mails, you will be notified for > messages that arrive to your subscribed mailboxes. > > the Store is a generic framework and each Mailbox implementation must > provide the means to save the information on disk. The JPA > implementation for example uses object relational mapping to map a > Java class to a relational table in a RDBMS. > Check out > http://svn.apache.org/repos/asf/james/mailbox/trunk/jpa/src/main/java/org/apache/james/mailbox/jpa/mail/model/JPAMailbox.java > to see how JPAMailbox class uses annotations to map fields to table > columns. That's why you can't use SimpleMessage, because OpenJPA would > not know how to save what field to what column. > > The Hbase implementation is more suitable for you to learn because it > explicitly saves/retrieves content to HBase, whereas in JPA you will > see a lot of annotations but the actual persistence is hidden. > > In order to build an implementation I suggest you start by > implementing the tests which will initially fail and then try to make > the failing tests pass one by one. This is the way I started and it > was clear. I also suggest you start by implementing > SubscriptionManager and MailboxManager first. MessageMannager and > Message related classes are harder. > > The API is pretty good so most of the work will be to implement the > *Mapper classes. Other than that you should probably do very little > work say for Managers. > > A word about the mappers: > > They are three of them: SubscriptionMapper, MailboxMapper and > MessageMapper. They are defined as interfaces (please have a look at > those interfaces) and provide CRUD (creat, read, update, delete) for > subscriptions, mailboxes and messages. They are used by *Managers to > do work in the Mailbox (NOTE: be aware that mailbox has many meanings: > the actual store for your emails (e.g. Apache Mailbox), one folder for > storing emails, etc. see http://en.wikipedia.org/wiki/Email_box ). > Mappers provide simple operations that are used by Managers and beyond > to do complex stuff. For example when a user reads a new message, the > server must perform some of the following: > > - access the mailbox > - find the message > - read the message > - update it's flags: UNREAD and maybe RECENT flag > - etc. > > So a user reading a message is a complex operation that spans multiple > simple opperations provided by Mapper implementations (see > updateFlags, findMessage, findMailbox, etc). > >> I'm not sure how I would do TDD. What to test? Who tests the tester? But >> maybe TDD will change my way of looking at the code, and proving >> assumptions. I still find it hard to read Java code that spans more than 5 >> classes. > > Try reading a book and most importantly: do exercises. Doing is the > only way to get better at stuff. > > I hope that you have a better understanding now and I wish you good > luck. Don't hesitate if you
svn commit: r1180841 - /james/server/trunk/pom.xml
Author: norman
Date: Mon Oct 10 09:31:05 2011
New Revision: 1180841
URL: http://svn.apache.org/viewvc?rev=1180841&view=rev
Log:
Move to protocols 1.6-beta1 as it was just released
Modified:
james/server/trunk/pom.xml
Modified: james/server/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/james/server/trunk/pom.xml?rev=1180841&r1=1180840&r2=1180841&view=diff
==
--- james/server/trunk/pom.xml (original)
+++ james/server/trunk/pom.xml Mon Oct 10 09:31:05 2011
@@ -1437,7 +1437,7 @@
0.4-SNAPSHOT
0.3-SNAPSHOT
${project.version}
-1.6-SNAPSHOT
+1.6-beta1
0.4
2.2.5
0.90.3
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
