Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
Back again. In DefaultProcessorChain, we know have createDefaultChain(chainEndProcessor, mailboxManager, subscriptionManager, statusResponseFactory) so mailbox and subscription can be seen on the same level, each playing role in the different processors. There are now 3 options: 1.- composition/stragety was the initial situation (before the pach) 2.- inheritance was the intermediate commit 3.- chain or responsibility (in the processor) is the current commit. I like the 3rd one. Tks, Eric On 22/08/2010 08:53, Eric Charles wrote: Hi, So Tim, you was also ok with optin 2 and finally Norman reverted to option 1 ? (not sure to be in line :) ?) I've looked at revision 987821: - SubscriptionManager is not used anymore in MailboxManager hirerachy (StoreMailboxManager,...) - The 3 delegate methods present in DelegatingMailboxManager are removed (so, yes, DelegatingMailboxManager is not delegating anymore, and we could rename it :), or merge with StoreMailboxManager - The ImapProcess is now responsible for the SubscriptionManager I suppose the spring-beans.xml is not committed according to these changes (imapProcessor and mailboxmanager constructors should be updated) I like the idea to leave an interface thats clearly describe the Subscription methods. Is there a particular reason to have now the DefaultImapProcessorFactory responsible for the SubscriptionManager ? I can see it's // with the MailboxManager. NioImapServer finally uses the imapProcessor bean. btw, if we talk Gof patterns, we went from a "Strategy" pattern to a "Chain of responsibility" pattern. So the question I'm wondering is "is it the responsibility of the the NioImapServer to process the mailbox, then the subscription" (it does it via the DefaultProcessorChain). I remain in favour of "strategy or chain", rather then inheritance. Tim, are the mapper considerations your're talking here related to IMAP-206 ? (not sure to understand the relations, maybe a separate thread would help) Tks, Eric On 21/08/2010 22:53, Tim-Christian Mundt wrote: Norman, I have not yet reviewed your recent commit. However, I'd like to remark that I was in favor of your last attempt. I just wanted to _additionally_: I think we should also merge them which would also simplify the package structure because we wouldn't need the .mail and .user packages anymore. Which means, not only merge the SubscriptionManager into the MailboxManager like you did, but also the SubscriptionMapper into the MailboxMapper. That would make the separation between .user and .mail superfluous. Does that make sense? Maybe your current attempt is still better, I haven't checked yet. Best Tim Am Samstag, den 21.08.2010, 22:08 +0200 schrieb Norman Maurer: Ok another attempt was made.. please review changes made in revision 987821 Thx, Norman 2010/8/21 Norman Maurer: Well I need to revert it ;) I will do so then.. Bye, Norman 2010/8/21 Norman Maurer: Hi Tim, comments inside.. 2010/8/21 Tim-Christian Mundt: Norman, you are right in that it was kinda double, so there should be some cleanup. My first attempt would have been to remove the subscription stuff from the MailboxManager (your option #1). The reason is that we always have a manager and its respective mapper. Now we have the MailboxManager with two Mappers. I think we should also merge them which would also simplify the package structure because we wouldn't need the .mail and .user packages anymore. Thats true I just thought it would be more easy to have not to many interfaces to implement. Anyway I would also be happy to move the subscripe stuff to any extra interface. I just don't like to have it duplicated so feel free to revert... One more thing concerning naming and stuff: Now the DelegatingMailboxManager is not really delegating anymore. Is there any good reason we should keep it separate from StoreMailboxManager? If not I'd rather have a little bigger class but fewer hierarchy levels. I need to review.. Any thoughts? Tim Am Samstag, den 21.08.2010, 10:23 +0200 schrieb Norman Maurer: I just committed the changes.. If anyone thinks its a bad idea we can revert it anyway.. https://issues.apache.org/jira/browse/IMAP-205 Bye, Norman 2010/8/21 Norman Maurer: Hi there, after looking again at the IMAP api I'm in favor of removing the org.apache.james.imap.store.Subscriper interface and merge the implementations with the MailboxManager implementations. Thats because the Subsciper interface has 3 methods, all of the methods are already in MailboxManager. So the MailboxManager just wraps the Subscriper implementation and delegate the call to it. So there are two solutions to this: 1) Remove the methods from MailboxManager and move the Subscriper interface to the mailbox api 2) Remove the Subscriper interface from store api and merge the implementations As I stated before I would prefer 2). WDYT ? Bye, Norman -
[jira] Created: (IMAP-207) Rename Document to Message and Mailbox to MessageManager
Rename Document to Message and Mailbox to MessageManager Key: IMAP-207 URL: https://issues.apache.org/jira/browse/IMAP-207 Project: JAMES Imap Issue Type: Task Reporter: Eric Charles Assignee: Eric Charles Rename org.apache.james.imap.store.mail.model.Document interface to org.apache.james.imap.store.mail..Message This will be inline with the implementations and more specific to mails, Rename org.apache.james.imap.mailbox.Mailbox to org.apache.james.imap.mailbox.MessageManager This will be in line with the hierarchy it represents. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
Hi Tim, 2010/8/21 Tim-Christian Mundt : > Norman, > > I have not yet reviewed your recent commit. However, I'd like to remark > that I was in favor of your last attempt. I just wanted to > _additionally_: ok :) > >> >>> I think we should also merge them which >> >>> would also simplify the package structure because we wouldn't need >> >>> the .mail and .user packages anymore. > > Which means, not only merge the SubscriptionManager into the > MailboxManager like you did, but also the SubscriptionMapper into the > MailboxMapper. That would make the separation between .user and .mail > superfluous. > > Does that make sense? Maybe your current attempt is still better, I > haven't checked yet. Yes this makes sense too.. The question is do we want to have an extra interface for subscriptions or not ? The problem with the current patch is that its not really optimal how the startProcessing... stopProcessing is used.. Because the SubscriptionManager does not have such methods and so it can lead to leaking resources if the methods in MailboxManager is not called.. Thats a problem cause it would be possible to use the SubscriptionManager alone.. If we go backto option 1) we don't have this problems.. So I'm still not sure what solution is the best .. > > Best > Tim > > Am Samstag, den 21.08.2010, 22:08 +0200 schrieb Norman Maurer: >> Ok another attempt was made.. please review changes made in revision 987821 >> >> Thx, >> Norman >> >> 2010/8/21 Norman Maurer : >> > Well I need to revert it ;) I will do so then.. >> > >> > Bye, >> > Norman >> > >> > >> > 2010/8/21 Norman Maurer : >> >> Hi Tim, >> >> >> >> comments inside.. >> >> >> >> 2010/8/21 Tim-Christian Mundt : >> >>> Norman, >> >>> >> >>> you are right in that it was kinda double, so there should be some >> >>> cleanup. My first attempt would have been to remove the subscription >> >>> stuff from the MailboxManager (your option #1). The reason is that we >> >>> always have a manager and its respective mapper. Now we have the >> >>> MailboxManager with two Mappers. I think we should also merge them which >> >>> would also simplify the package structure because we wouldn't need >> >>> the .mail and .user packages anymore. >> >> >> >> Thats true I just thought it would be more easy to have not to many >> >> interfaces to implement. Anyway I would also be happy to move the >> >> subscripe stuff to any extra interface. I just don't like to have it >> >> duplicated so feel free to revert... >> >> >> >>> >> >>> One more thing concerning naming and stuff: Now the >> >>> DelegatingMailboxManager is not really delegating anymore. Is there any >> >>> good reason we should keep it separate from StoreMailboxManager? If not >> >>> I'd rather have a little bigger class but fewer hierarchy levels. >> >> >> >> I need to review.. >> >> >> >>> >> >>> Any thoughts? >> >>> >> >>> Tim >> >>> >> >>> Am Samstag, den 21.08.2010, 10:23 +0200 schrieb Norman Maurer: >> I just committed the changes.. If anyone thinks its a bad idea we can >> revert it anyway.. >> >> https://issues.apache.org/jira/browse/IMAP-205 >> >> Bye, >> Norman >> >> 2010/8/21 Norman Maurer : >> > Hi there, >> > >> > after looking again at the IMAP api I'm in favor of removing the >> > org.apache.james.imap.store.Subscriper interface and merge the >> > implementations with the MailboxManager implementations. Thats because >> > the Subsciper interface has 3 methods, all of the methods are already >> > in MailboxManager. So the MailboxManager just wraps the Subscriper >> > implementation and delegate the call to it. >> > >> > So there are two solutions to this: >> > >> > 1) Remove the methods from MailboxManager and move the Subscriper >> > interface to the mailbox api >> > 2) Remove the Subscriper interface from store api and merge the >> > implementations >> > >> > As I stated before I would prefer 2). >> > >> > WDYT ? >> > >> > Bye, >> > Norman >> > >> >> - >> 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 >> >>> >> >>> >> >> >> >> Bye, >> >> Norman >> >> >> > >> Bye, Norman - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
Hi Eric.. 2010/8/22 Eric Charles : > Hi, > > So Tim, you was also ok with optin 2 and finally Norman reverted to option 1 > ? (not sure to be in line :) ?) > Seems so.. > I've looked at revision 987821: > - SubscriptionManager is not used anymore in MailboxManager hirerachy > (StoreMailboxManager,...) > - The 3 delegate methods present in DelegatingMailboxManager are removed > (so, yes, DelegatingMailboxManager is not delegating anymore, and we could > rename it :), or merge with StoreMailboxManager > - The ImapProcess is now responsible for the SubscriptionManager > > I suppose the spring-beans.xml is not committed according to these changes > (imapProcessor and mailboxmanager constructors should be updated) yeah I will update the springs-beans.xml once we know howto process. > > I like the idea to leave an interface thats clearly describe the > Subscription methods. > Is there a particular reason to have now the DefaultImapProcessorFactory > responsible for the SubscriptionManager ? > I can see it's // with the MailboxManager. > NioImapServer finally uses the imapProcessor bean. We need the Subscription stuff in some Processors, thats why we need it here. > > btw, if we talk Gof patterns, we went from a "Strategy" pattern to a "Chain > of responsibility" pattern. > So the question I'm wondering is "is it the responsibility of the the > NioImapServer to process the mailbox, then the subscription" (it does it via > the DefaultProcessorChain). > I remain in favour of "strategy or chain", rather then inheritance. > > Tim, are the mapper considerations your're talking here related to IMAP-206 > ? (not sure to understand the relations, maybe a separate thread would help) > > Tks, > > Eric > > > On 21/08/2010 22:53, Tim-Christian Mundt wrote: >> >> Norman, >> >> I have not yet reviewed your recent commit. However, I'd like to remark >> that I was in favor of your last attempt. I just wanted to >> _additionally_: >> >> I think we should also merge them which >> would also simplify the package structure because we wouldn't need >> the .mail and .user packages anymore. >> >> Which means, not only merge the SubscriptionManager into the >> MailboxManager like you did, but also the SubscriptionMapper into the >> MailboxMapper. That would make the separation between .user and .mail >> superfluous. >> >> Does that make sense? Maybe your current attempt is still better, I >> haven't checked yet. >> >> Best >> Tim >> >> Am Samstag, den 21.08.2010, 22:08 +0200 schrieb Norman Maurer: >>> >>> Ok another attempt was made.. please review changes made in revision >>> 987821 >>> >>> Thx, >>> Norman >>> >>> 2010/8/21 Norman Maurer: Well I need to revert it ;) I will do so then.. Bye, Norman 2010/8/21 Norman Maurer: > > Hi Tim, > > comments inside.. > > 2010/8/21 Tim-Christian Mundt: >> >> Norman, >> >> you are right in that it was kinda double, so there should be some >> cleanup. My first attempt would have been to remove the subscription >> stuff from the MailboxManager (your option #1). The reason is that we >> always have a manager and its respective mapper. Now we have the >> MailboxManager with two Mappers. I think we should also merge them >> which >> would also simplify the package structure because we wouldn't need >> the .mail and .user packages anymore. > > Thats true I just thought it would be more easy to have not to many > interfaces to implement. Anyway I would also be happy to move the > subscripe stuff to any extra interface. I just don't like to have it > duplicated so feel free to revert... > >> One more thing concerning naming and stuff: Now the >> DelegatingMailboxManager is not really delegating anymore. Is there >> any >> good reason we should keep it separate from StoreMailboxManager? If >> not >> I'd rather have a little bigger class but fewer hierarchy levels. > > I need to review.. > >> Any thoughts? >> >> Tim >> >> Am Samstag, den 21.08.2010, 10:23 +0200 schrieb Norman Maurer: >>> >>> I just committed the changes.. If anyone thinks its a bad idea we can >>> revert it anyway.. >>> >>> https://issues.apache.org/jira/browse/IMAP-205 >>> >>> Bye, >>> Norman >>> >>> 2010/8/21 Norman Maurer: Hi there, after looking again at the IMAP api I'm in favor of removing the org.apache.james.imap.store.Subscriper interface and merge the implementations with the MailboxManager implementations. Thats because the Subsciper interface has 3 methods, all of the methods are already in MailboxManager. So the MailboxManager just wraps the Subscriper implementation and delegate the call to it. So there are two solutions to this: 1) Remove the methods
[jira] Commented: (IMAP-206) Straighten Non-/TransactionalMapper Hierarchy
[ https://issues.apache.org/jira/browse/IMAP-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901143#action_12901143 ] Eric Charles commented on IMAP-206: --- I've svn up --revision 987444 and tried to apply the patch, but it's complaining files are not present (Mapper, AbstractTransactionalMapper, TransactionalMapper). Never mind, with the explanation you gave, I now understand much better the way mappers should be considered. So if james store is still working with that hierarchy, I would like to see it in trunk. > Straighten Non-/TransactionalMapper Hierarchy > - > > Key: IMAP-206 > URL: https://issues.apache.org/jira/browse/IMAP-206 > Project: JAMES Imap > Issue Type: Improvement >Reporter: Tim-Christian Mundt >Priority: Minor > Attachments: TransactionalMappers.patch > > > There are two things I find odd about the Mapper hierarchy: > a) NonTransactionalMapper extends TransactionalMapper which is semantically > confusing. > b) The Store API refers to TransactionalMappers where any Mapper > (transactional or not) is appropriate. Moreover, the Mappers inherit from > TransactionalMapper two times: once via AbstractTransactionalMapper and once > via Message/Mailbox/SubscriptionMapper. > I'd like to have it more straight forward: > 1) Have a base Mapper, which gets implemented by a TransactionalMapper and a > NonTransactionalMapper (both abstract). > 2) The Message/Mailbox/SubscriptionMapper interfaces should not care about > transactions and thus not inherit at all. > 3) The implementations extend one of Transactional- or NonTransactionalMapper > and implement one of Message/Mailbox/SubscriptionMapper. > This way the hierarchy is clearer and function (message...) and transaction > are separated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
See comments after. Eric On 22/08/2010 10:12, Norman Maurer wrote: Which means, not only merge the SubscriptionManager into the MailboxManager like you did, but also the SubscriptionMapper into the MailboxMapper. That would make the separation between .user and .mail superfluous. Does that make sense? Maybe your current attempt is still better, I haven't checked yet. Yes this makes sense too.. The question is do we want to have an extra interface for subscriptions or not ? The problem with the current patch is that its not really optimal how the startProcessing... stopProcessing is used.. Because the SubscriptionManager does not have such methods and so it can lead to leaking resources if the methods in MailboxManager is not called.. Thats a problem cause it would be possible to use the SubscriptionManager alone.. If we go backto option 1) we don't have this problems.. So I'm still not sure what solution is the best .. DefaultProcessorChain is responsible to invoke the MailboxManager and the SubscriptionManager. So the behaviour of both is controlled by an external compontent, the DefaultProcessorChain (they are coordinated/controlled by something). But it's true that SubscriptionManager could be used independently of MailboxManager, and one depending on the other, this could produce unwanted effects (didn't look which one...). An important point is the following: Subscription are links between JamesUser and Mailbox : right ? We are in a "mind" to let the James Admin user configure the way he want to persist its mails, its users,.. Let's take the example of JCR mailbox store with a JPA user store. Where would the subscription be persisted : JCR or JPA ? And why the user wouldn't be allowed to persist its subscriptions in (I take any example) : another DB, a LDAP, a noSQL store,... If we think we should give freedom and tools to 3rd party to persist where they want the different James domain aspects, leaving the aspects separated in different is not a bad thing. If we think that a Subscription management is on the same level as Mailbox Management (seen from here, it seems), we could also add the start/stop processing and addListerner methods on it (it can always be useful to be notified of a subscription). - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
Hi, comments inline again ;) 2010/8/22 Eric Charles : > See comments after. > Eric > > On 22/08/2010 10:12, Norman Maurer wrote: >>> >>> Which means, not only merge the SubscriptionManager into the >>> MailboxManager like you did, but also the SubscriptionMapper into the >>> MailboxMapper. That would make the separation between .user and .mail >>> superfluous. >>> >>> Does that make sense? Maybe your current attempt is still better, I >>> haven't checked yet. >> >> Yes this makes sense too.. The question is do we want to have an extra >> interface for subscriptions or not ? The problem with the current >> patch is that its not really optimal how the startProcessing... >> stopProcessing is used.. Because the SubscriptionManager does not have >> such methods and so it can lead to leaking resources if the methods in >> MailboxManager is not called.. Thats a problem cause it would be >> possible to use the SubscriptionManager alone.. >> >> If we go backto option 1) we don't have this problems.. >> >> So I'm still not sure what solution is the best .. >> > DefaultProcessorChain is responsible to invoke the MailboxManager and the > SubscriptionManager. > So the behaviour of both is controlled by an external compontent, the > DefaultProcessorChain (they are coordinated/controlled by something). > But it's true that SubscriptionManager could be used independently of > MailboxManager, and one depending on the other, this could produce unwanted > effects (didn't look which one...). I don't see any side effects here.. > > An important point is the following: Subscription are links between > JamesUser and Mailbox : right ? Not 100%.. Subscriptions links users to Mailboxes. The users are just Strings and nothing more. So its not coupled to james server in any way. > We are in a "mind" to let the James Admin user configure the way he want to > persist its mails, its users,.. > Let's take the example of JCR mailbox store with a JPA user store. Where > would the subscription be persisted : JCR or JPA ? If we go with 1) its JCR, if we go with 2) its up to the admin. > And why the user wouldn't be allowed to persist its subscriptions in (I take > any example) : another DB, a LDAP, a noSQL store,... > If we think we should give freedom and tools to 3rd party to persist where > they want the different James domain aspects, leaving the aspects separated > in different is not a bad thing. > > If we think that a Subscription management is on the same level as Mailbox > Management (seen from here, it seems), we could also add the start/stop > processing and addListerner methods on it (it can always be useful to be > notified of a subscription). true enough Just as a side-note... For example the subscription stuff is not really necessary for using MailboxManager in non-imap enviroments (for example pop3). Bye, Norman - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (IMAP-206) Straighten Non-/TransactionalMapper Hierarchy
[ https://issues.apache.org/jira/browse/IMAP-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-206. Assignee: Norman Maurer Fix Version/s: 0.1 Resolution: Fixed merged in.. The patch was a bit broken ;) > Straighten Non-/TransactionalMapper Hierarchy > - > > Key: IMAP-206 > URL: https://issues.apache.org/jira/browse/IMAP-206 > Project: JAMES Imap > Issue Type: Improvement >Reporter: Tim-Christian Mundt >Assignee: Norman Maurer >Priority: Minor > Fix For: 0.1 > > Attachments: TransactionalMappers.patch > > > There are two things I find odd about the Mapper hierarchy: > a) NonTransactionalMapper extends TransactionalMapper which is semantically > confusing. > b) The Store API refers to TransactionalMappers where any Mapper > (transactional or not) is appropriate. Moreover, the Mappers inherit from > TransactionalMapper two times: once via AbstractTransactionalMapper and once > via Message/Mailbox/SubscriptionMapper. > I'd like to have it more straight forward: > 1) Have a base Mapper, which gets implemented by a TransactionalMapper and a > NonTransactionalMapper (both abstract). > 2) The Message/Mailbox/SubscriptionMapper interfaces should not care about > transactions and thus not inherit at all. > 3) The implementations extend one of Transactional- or NonTransactionalMapper > and implement one of Message/Mailbox/SubscriptionMapper. > This way the hierarchy is clearer and function (message...) and transaction > are separated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
svn commit: r987884 - in /james/imap/trunk: jcr/src/main/java/org/apache/james/imap/jcr/ jpa/src/main/java/org/apache/james/imap/jpa/ maildir/src/main/java/org/apache/james/imap/maildir/mail/ maildir/
Author: norman
Date: Sun Aug 22 12:13:40 2010
New Revision: 987884
URL: http://svn.apache.org/viewvc?rev=987884&view=rev
Log:
Straighten Non-/TransactionalMapper Hierarchy (IMAP-206). Thx to Tim-Christian
Mundt for the patch :)
Added:
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/transaction/Mapper.java
- copied, changed from r987768,
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/transaction/TransactionalMapper.java
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/transaction/TransactionalMapper.java
- copied, changed from r987768,
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/transaction/AbstractTransactionalMapper.java
Removed:
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/transaction/AbstractTransactionalMapper.java
Modified:
james/imap/trunk/jcr/src/main/java/org/apache/james/imap/jcr/AbstractJCRMapper.java
james/imap/trunk/jcr/src/main/java/org/apache/james/imap/jcr/JCRMailboxManager.java
james/imap/trunk/jpa/src/main/java/org/apache/james/imap/jpa/JPATransactionalMapper.java
james/imap/trunk/maildir/src/main/java/org/apache/james/imap/maildir/mail/MaildirMailboxMapper.java
james/imap/trunk/maildir/src/main/java/org/apache/james/imap/maildir/mail/MaildirMessageMapper.java
james/imap/trunk/maildir/src/main/java/org/apache/james/imap/maildir/user/MaildirSubscriptionMapper.java
james/imap/trunk/memory/src/main/java/org/apache/james/imap/inmemory/InMemoryMailboxSessionMapperFactory.java
james/imap/trunk/memory/src/main/java/org/apache/james/imap/inmemory/InMemorySubscriptionManager.java
james/imap/trunk/memory/src/main/java/org/apache/james/imap/inmemory/mail/InMemoryMailboxMapper.java
james/imap/trunk/memory/src/main/java/org/apache/james/imap/inmemory/mail/InMemoryMessageMapper.java
james/imap/trunk/memory/src/main/java/org/apache/james/imap/inmemory/user/InMemorySubscriptionMapper.java
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/MapperStoreMessageManager.java
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/StoreMailboxManager.java
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/StoreSubscriptionManager.java
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/mail/MailboxMapper.java
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/mail/MessageMapper.java
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/transaction/NonTransactionalMapper.java
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/user/SubscriptionMapper.java
Modified:
james/imap/trunk/jcr/src/main/java/org/apache/james/imap/jcr/AbstractJCRMapper.java
URL:
http://svn.apache.org/viewvc/james/imap/trunk/jcr/src/main/java/org/apache/james/imap/jcr/AbstractJCRMapper.java?rev=987884&r1=987883&r2=987884&view=diff
==
---
james/imap/trunk/jcr/src/main/java/org/apache/james/imap/jcr/AbstractJCRMapper.java
(original)
+++
james/imap/trunk/jcr/src/main/java/org/apache/james/imap/jcr/AbstractJCRMapper.java
Sun Aug 22 12:13:40 2010
@@ -25,7 +25,7 @@ import org.apache.commons.logging.Log;
import org.apache.james.imap.api.display.HumanReadableText;
import org.apache.james.imap.mailbox.MailboxException;
import org.apache.james.imap.mailbox.MailboxSession;
-import org.apache.james.imap.store.transaction.AbstractTransactionalMapper;
+import org.apache.james.imap.store.transaction.TransactionalMapper;
/**
* Abstract Mapper base class for Level 1 Implementations of JCR. So no real
transaction management is used.
@@ -33,7 +33,7 @@ import org.apache.james.imap.store.trans
* The Session.save() will get called on commit() method,
session.refresh(false) on rollback, and session.refresh(true) on begin()
*
*/
-public abstract class AbstractJCRMapper extends AbstractTransactionalMapper
implements JCRImapConstants {
+public abstract class AbstractJCRMapper extends TransactionalMapper implements
JCRImapConstants {
public final static String MAILBOXES_PATH = "mailboxes";
private final Log logger;
Modified:
james/imap/trunk/jcr/src/main/java/org/apache/james/imap/jcr/JCRMailboxManager.java
URL:
http://svn.apache.org/viewvc/james/imap/trunk/jcr/src/main/java/org/apache/james/imap/jcr/JCRMailboxManager.java?rev=987884&r1=987883&r2=987884&view=diff
==
---
james/imap/trunk/jcr/src/main/java/org/apache/james/imap/jcr/JCRMailboxManager.java
(original)
+++
james/imap/trunk/jcr/src/main/java/org/apache/james/imap/jcr/JCRMailboxManager.java
Sun Aug 22 12:13:40 2010
@@ -30,7 +30,7 @@ import org.apache.james.imap.store.Authe
import org.apache.james.imap.store.StoreMailboxManager;
import org.apache.james.imap.store.MapperStoreMessageManager;
import org.apache.james.
[jira] Closed: (IMAP-108) Make it configurable to allow usage of Container managed Transaction
[ https://issues.apache.org/jira/browse/IMAP-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer closed IMAP-108. -- Resolution: Won't Fix No need > Make it configurable to allow usage of Container managed Transaction > > > Key: IMAP-108 > URL: https://issues.apache.org/jira/browse/IMAP-108 > Project: JAMES Imap > Issue Type: Improvement > Components: JPA Mailbox >Affects Versions: 0.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Assigned: (IMAP-188) renaming INBOX should move messages
[ https://issues.apache.org/jira/browse/IMAP-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer reassigned IMAP-188: -- Assignee: Norman Maurer > renaming INBOX should move messages > --- > > Key: IMAP-188 > URL: https://issues.apache.org/jira/browse/IMAP-188 > Project: JAMES Imap > Issue Type: Bug > Components: Mailbox >Reporter: Tim-Christian Mundt >Assignee: Norman Maurer > Attachments: renameINBOX.patch > > > RFC3501 says: > Renaming INBOX is permitted, and has special behavior. It moves > all messages in INBOX to a new mailbox with the given name, > leaving INBOX empty. If the server implementation supports > inferior hierarchical names of INBOX, these are unaffected by a > rename of INBOX. > This is not implemented in James, but should be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
svn commit: r987895 - /james/imap/trunk/store/src/main/java/org/apache/james/imap/store/StoreMailboxManager.java
Author: norman
Date: Sun Aug 22 12:59:05 2010
New Revision: 987895
URL: http://svn.apache.org/viewvc?rev=987895&view=rev
Log:
renaming INBOX should move messages to new Mailbox (IMAP-188)
Modified:
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/StoreMailboxManager.java
Modified:
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/StoreMailboxManager.java
URL:
http://svn.apache.org/viewvc/james/imap/trunk/store/src/main/java/org/apache/james/imap/store/StoreMailboxManager.java?rev=987895&r1=987894&r2=987895&view=diff
==
---
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/StoreMailboxManager.java
(original)
+++
james/imap/trunk/store/src/main/java/org/apache/james/imap/store/StoreMailboxManager.java
Sun Aug 22 12:59:05 2010
@@ -23,7 +23,10 @@ import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
+import javax.mail.Flags;
+
import org.apache.commons.logging.Log;
+import org.apache.james.imap.api.ImapConstants;
import org.apache.james.imap.api.MailboxPath;
import org.apache.james.imap.mailbox.MailboxConstants;
import org.apache.james.imap.mailbox.MailboxException;
@@ -185,7 +188,7 @@ public abstract class StoreMailboxManage
mailbox.setName(to.getName());
mapper.save(mailbox);
-changeMailboxName(from, to, session);
+dispatcher.mailboxRenamed(from, to, session.getSessionId());
// rename submailboxes
MailboxPath children = new
MailboxPath(MailboxConstants.USER_NAMESPACE, from.getUser(), from.getName() +
MailboxConstants.DEFAULT_DELIMITER + "%");
@@ -195,13 +198,37 @@ public abstract class StoreMailboxManage
for (Mailbox sub : subMailboxes) {
final String subOriginalName = sub.getName();
final String subNewName = to.getName() +
subOriginalName.substring(from.getName().length());
-sub.setName(subNewName);
-mapper.save(sub);
+final MailboxPath fromPath = new MailboxPath(children,
subOriginalName);
+final MailboxPath toPath = new MailboxPath(children,
subNewName);
+if
(sub.getName().equalsIgnoreCase(ImapConstants.INBOX_NAME) == false) {
+
+sub.setName(subNewName);
+mapper.save(sub);
+dispatcher.mailboxRenamed(fromPath, toPath,
session.getSessionId());
+
+if (log.isDebugEnabled())
+log.debug("Rename mailbox sub-mailbox " +
subOriginalName + " to " + subNewName);
+
+} else {
+
+// if the mailbox is INBOX we need to move move
the messages
+// https://issues.apache.org/jira/browse/IMAP-188
+MessageRange range = MessageRange.all();
+
+// create the mailbox if it not exist yet
+if (mailboxExists(toPath, session) == false) {
+createMailbox(toPath, session);
+}
+copyMessages(range, fromPath, toPath, session);
+
+org.apache.james.imap.mailbox.Mailbox inbox =
getMailbox(fromPath, session);
+inbox.setFlags(new Flags(Flags.Flag.DELETED),
true, false, range, session);
+inbox.expunge(range, session);
+
+}
+
-changeMailboxName(new MailboxPath(children,
subOriginalName), new MailboxPath(children, subNewName), session);
-if (log.isDebugEnabled())
-log.debug("Rename mailbox sub-mailbox " +
subOriginalName + " to " + subNewName);
}
} finally {
lock.unlock(children);
@@ -212,15 +239,7 @@ public abstract class StoreMailboxManage
});
}
-
-/**
- * Changes the name of the mailbox instance in the cache.
- * @param from not null
- * @param to not null
- */
-private void changeMailboxName(MailboxPath from, MailboxPath to,
MailboxSession session) {
-dispatcher.mailboxRenamed(from, to, session.getSessionId());
-}
+
/*
* (non-Javadoc)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (IMAP-188) renaming INBOX should move messages
[ https://issues.apache.org/jira/browse/IMAP-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-188. Fix Version/s: 0.1 Resolution: Fixed renaming INBOX now move the messages. I implemented it as "generic" solution.. > renaming INBOX should move messages > --- > > Key: IMAP-188 > URL: https://issues.apache.org/jira/browse/IMAP-188 > Project: JAMES Imap > Issue Type: Bug > Components: Mailbox >Reporter: Tim-Christian Mundt >Assignee: Norman Maurer > Fix For: 0.1 > > Attachments: renameINBOX.patch > > > RFC3501 says: > Renaming INBOX is permitted, and has special behavior. It moves > all messages in INBOX to a new mailbox with the given name, > leaving INBOX empty. If the server implementation supports > inferior hierarchical names of INBOX, these are unaffected by a > rename of INBOX. > This is not implemented in James, but should be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
one more inline :) On 22/08/2010 13:58, Norman Maurer wrote: Not 100%.. Subscriptions links users to Mailboxes. The users are just Strings and nothing more. So its not coupled to james server in any way. Yeah, these are "soft links". A "Subscription store" could be different from the "Mailbox store" (so we have links via String). Example: - Users are stored in LDAP tks to james-server. - Mailbox in DB via JPA. - Subscription "soft link" LDAP to DB and these "soft links" are store "anywhere" defined by the admin (in spring-beans.xml). (snippped...) Just as a side-note... For example the subscription stuff is not really necessary for using MailboxManager in non-imap enviroments (for example pop3). True enough. I re-read the pop3 case, and I see one more argument to leave the SubscriptionManager independent of the MailboxManager. So http://svn.apache.org/viewvc?rev=987821&view=rev "Move the Subscriper to the mailbox api and rename it SubscriptionManager..." makes all its sense. There's still the open question on start/stopProcessing and listener (to be duplicated in Mailbox/SubscriptionManager or externalized ?). To take a decision , we should also consider that operations need to be atomic, so encapsulate the Mailbox/SubscriptionManager processing. So "externalize/encapsulate" makes some sense, as you communicated me ? - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (IMAP-153) JCR Storage structure uses files as imap folders hiding the structure and exposing the underlying storage to users (potentially)
[ https://issues.apache.org/jira/browse/IMAP-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norman Maurer resolved IMAP-153. Resolution: Won't Fix We dedicited to keep the current node structure > JCR Storage structure uses files as imap folders hiding the structure and > exposing the underlying storage to users (potentially) > > > Key: IMAP-153 > URL: https://issues.apache.org/jira/browse/IMAP-153 > Project: JAMES Imap > Issue Type: Improvement > Components: JCR Mailbox >Affects Versions: 0.1 >Reporter: Ian Boston > > Currently message and folder storage share the same single parent hierachy so > that If I have 2 imap folders INBOX and INBOX/test the JCR node structure is > .../INBOX/2010/05/31/message121231 > .../INBOX.test/2010/05/31/message345345 > Which results in the date structure being part of the folder and the imap > folder not being represented as a folder. It also means that messages really > are moved, when they are moved. > The proposed layout is to move the folders into their own hierarchy and have > the messages in a sepeate hierachy, still one per user > so a message in JCR looks like this (my uid is ieb) > ...ieb/store/2010/06/08/message121243 > - jamesMailboimapfolders = [ > a3de-34ed-2aef-2134-2e34, > a3de-34ed-2aef-2134-2e35 >] > > and the folders like this > ...ieb/INBOX > - rep:uuid = a3de-34ed-2aef-2134-2e34 > ...ieb/INBOX/test > - rep:uuid = a3de-34ed-2aef-2134-2e35 > where jamesMailbox:imapfolders is a REFERENCE type in cnd > to list a folder, is a query > message121243 appears in both INBOX and INBOX/test > There would need to be some changes to the webdav classes/plugins to make > this work in webdav. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
Comments inline.. 2010/8/22 Eric Charles : > one more inline :) > > On 22/08/2010 13:58, Norman Maurer wrote: >> >> Not 100%.. Subscriptions links users to Mailboxes. The users are just >> Strings and nothing more. So its not coupled to james server in any >> way. >> > Yeah, these are "soft links". > A "Subscription store" could be different from the "Mailbox store" (so we > have links via String). > Example: > - Users are stored in LDAP tks to james-server. > - Mailbox in DB via JPA. > - Subscription "soft link" LDAP to DB and these "soft links" are store > "anywhere" defined by the admin (in spring-beans.xml). > >> (snippped...) >> Just as a side-note... For example the subscription stuff is not >> really necessary for using MailboxManager in non-imap enviroments (for >> example pop3). >> > True enough. > I re-read the pop3 case, and I see one more argument to leave the > SubscriptionManager independent of the MailboxManager. > So http://svn.apache.org/viewvc?rev=987821&view=rev "Move the Subscriper to > the mailbox api and rename it SubscriptionManager..." makes all its sense. > > There's still the open question on start/stopProcessing and listener (to be > duplicated in Mailbox/SubscriptionManager or externalized ?). > To take a decision , we should also consider that operations need to be > atomic, so encapsulate the Mailbox/SubscriptionManager processing. > So "externalize/encapsulate" makes some sense, as you communicated me ? > I don't know yet.. whats you preference ? Bye, Norman - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Assigned: (JDKIM-19) Change scope on 2 variables in DKIMSign to support subclassing
[ https://issues.apache.org/jira/browse/JDKIM-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara reassigned JDKIM-19: Assignee: Stefano Bagnara > Change scope on 2 variables in DKIMSign to support subclassing > -- > > Key: JDKIM-19 > URL: https://issues.apache.org/jira/browse/JDKIM-19 > Project: JAMES jDKIM > Issue Type: Improvement > Components: mailet >Affects Versions: 0.2 > Environment: software, mailet >Reporter: Jerry Malcolm >Assignee: Stefano Bagnara > Fix For: 0.2 > > > I need to have separate private keys for DKIM for different domains that I > host on my server. I plan to create a database table that looks up the > private key based on the domain. I figured I could subclass your DKIMSign > mailet, override the service method, set the privateKey and > signatureTemplate variables and then call the parent service method. But it > turns out that the privateKey and signatureTemplate variables are scoped to > 'private'. I know I can just clone the entire method or even the entire > java class file. But I'd much prefer to inherit everything other than that > one little change I need. But I can't do it with private scope on the key > and template. > Request to change scope on pfivateKey and signatureTemplate variables from > private to protected to support subclassing of this mailet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Updated: (JDKIM-19) Change scope on 2 variables in DKIMSign to support subclassing
[ https://issues.apache.org/jira/browse/JDKIM-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara updated JDKIM-19: - Fix Version/s: 0.2 Affects Version/s: 0.2 > Change scope on 2 variables in DKIMSign to support subclassing > -- > > Key: JDKIM-19 > URL: https://issues.apache.org/jira/browse/JDKIM-19 > Project: JAMES jDKIM > Issue Type: Improvement > Components: mailet >Affects Versions: 0.2 > Environment: software, mailet >Reporter: Jerry Malcolm >Assignee: Stefano Bagnara > Fix For: 0.2 > > > I need to have separate private keys for DKIM for different domains that I > host on my server. I plan to create a database table that looks up the > private key based on the domain. I figured I could subclass your DKIMSign > mailet, override the service method, set the privateKey and > signatureTemplate variables and then call the parent service method. But it > turns out that the privateKey and signatureTemplate variables are scoped to > 'private'. I know I can just clone the entire method or even the entire > java class file. But I'd much prefer to inherit everything other than that > one little change I need. But I can't do it with private scope on the key > and template. > Request to change scope on pfivateKey and signatureTemplate variables from > private to protected to support subclassing of this mailet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Updated: (JDKIM-18) jdkim verify(InputStream) doesn't clean up temp files until shutdown
[ https://issues.apache.org/jira/browse/JDKIM-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara updated JDKIM-18: - Fix Version/s: 0.2 > jdkim verify(InputStream) doesn't clean up temp files until shutdown > > > Key: JDKIM-18 > URL: https://issues.apache.org/jira/browse/JDKIM-18 > Project: JAMES jDKIM > Issue Type: Bug > Components: library >Affects Versions: 0.2 > Environment: Verified this in solaris 10 and ubuntu 10.04 > java 1.6.0_13 >Reporter: Ben Aldrich >Assignee: Stefano Bagnara >Priority: Critical > Fix For: 0.2 > > > When you pass jdkim an input stream like so : > new DKIMVerifier().verify(new ByteArrayInputStream(sb.toString().getBytes())); > the jkdim impl/Message.java creates a mime4j temp file that doesn't get > deleted until the application exits. This causes any system that runs as a > daemon to eventually run out of disk space. > I did a quick test and replaced Message.java with my own implementation using > the regular javax MimeMessage to pull out the headers and the app no longer > creates the temp files. This isn't really a good solution though because now > I can't pass simple canonicalization. I don't know mime4j very well but > digging through the source it only sets the deleteOnExit flag by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
svn commit: r988001 - in /james/server/trunk: imapserver/src/main/java/org/apache/james/imapserver/ pop3server/src/test/java/org/apache/james/pop3server/ spring-deployment/src/main/config/james/
Author: norman
Date: Mon Aug 23 06:42:37 2010
New Revision: 988001
URL: http://svn.apache.org/viewvc?rev=988001&view=rev
Log:
Adjust code and xml to match current imap trunk
Modified:
james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/UserMetaDataRepositorySubscripter.java
james/server/trunk/pop3server/src/test/java/org/apache/james/pop3server/AbstractAsyncPOP3ServerTest.java
james/server/trunk/spring-deployment/src/main/config/james/spring-beans.xml
Modified:
james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/UserMetaDataRepositorySubscripter.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/UserMetaDataRepositorySubscripter.java?rev=988001&r1=988000&r2=988001&view=diff
==
---
james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/UserMetaDataRepositorySubscripter.java
(original)
+++
james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/UserMetaDataRepositorySubscripter.java
Mon Aug 23 06:42:37 2010
@@ -33,12 +33,12 @@ import org.apache.james.api.user.UsersRe
import org.apache.james.imap.api.display.HumanReadableText;
import org.apache.james.imap.mailbox.MailboxSession;
import org.apache.james.imap.mailbox.SubscriptionException;
-import org.apache.james.imap.store.Subscriber;
+import org.apache.james.imap.mailbox.SubscriptionManager;
/**
*
*/
-public class UserMetaDataRepositorySubscripter implements Subscriber {
+public class UserMetaDataRepositorySubscripter implements SubscriptionManager {
public static final String META_DATA_KEY =
"org.apache.james.IMAP_SUBSCRIPTIONS";
Modified:
james/server/trunk/pop3server/src/test/java/org/apache/james/pop3server/AbstractAsyncPOP3ServerTest.java
URL:
http://svn.apache.org/viewvc/james/server/trunk/pop3server/src/test/java/org/apache/james/pop3server/AbstractAsyncPOP3ServerTest.java?rev=988001&r1=988000&r2=988001&view=diff
==
---
james/server/trunk/pop3server/src/test/java/org/apache/james/pop3server/AbstractAsyncPOP3ServerTest.java
(original)
+++
james/server/trunk/pop3server/src/test/java/org/apache/james/pop3server/AbstractAsyncPOP3ServerTest.java
Mon Aug 23 06:42:37 2010
@@ -43,7 +43,6 @@ import org.apache.james.api.user.UsersRe
import org.apache.james.imap.api.MailboxPath;
import org.apache.james.imap.inmemory.InMemoryMailboxManager;
import org.apache.james.imap.inmemory.InMemoryMailboxSessionMapperFactory;
-import org.apache.james.imap.inmemory.InMemorySubscriptionManager;
import org.apache.james.imap.mailbox.Mailbox;
import org.apache.james.imap.mailbox.MailboxConstants;
import org.apache.james.imap.mailbox.MailboxSession;
@@ -111,7 +110,7 @@ public abstract class AbstractAsyncPOP3S
public boolean isAuthentic(String userid, CharSequence passwd) {
return m_usersRepository.test(userid, passwd.toString());
}
-}, new InMemorySubscriptionManager(factory));
+});
serviceManager.put("mailboxmanager", manager);
Modified:
james/server/trunk/spring-deployment/src/main/config/james/spring-beans.xml
URL:
http://svn.apache.org/viewvc/james/server/trunk/spring-deployment/src/main/config/james/spring-beans.xml?rev=988001&r1=988000&r2=988001&view=diff
==
--- james/server/trunk/spring-deployment/src/main/config/james/spring-beans.xml
(original)
+++ james/server/trunk/spring-deployment/src/main/config/james/spring-beans.xml
Mon Aug 23 06:42:37 2010
@@ -282,7 +282,9 @@
-
+
+
+
@@ -300,15 +302,14 @@
-
+
-
-
+
@@ -348,16 +349,15 @@
-
+
-
-
-
+
+
-->
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
