Make the namespace handling consistent and predictable
------------------------------------------------------
Key: MAILBOX-167
URL: https://issues.apache.org/jira/browse/MAILBOX-167
Project: James Mailbox
Issue Type: Bug
Reporter: Jochen Gazda
Assignee: Norman Maurer
(1) in StoreMessageManager.isGroupFolder(MailboxSession), if the
present folder is the current user's INBOX, mailbox.getNamespace() and
session.getPersonalSpace() should return the same value, which they do
not. This makes some ACL commands to fail.
I could achieve the desired behavior when I changed this part of
SimpleMailboxSession constructor from
if (otherUsersSpace == null && (sharedSpaces == null ||
sharedSpaces.isEmpty())) {
this.personalSpace = "";
} else {
this.personalSpace = MailboxConstants.USER_NAMESPACE;
}
to
this.personalSpace = MailboxConstants.USER_NAMESPACE;
Can this cause any unwanted consequences?
(2) in AbstractMailboxProcessor.buildFullPath(ImapSession, String),
MailboxConstants.USER_NAMESPACE is used on two places where IMO
mailboxSession.getPersonalSpace() would be a better choice just for
the case that -- for whatever reason -- the session gets configured
differently. Is it a good idea?
(3) I find the rewriting of "" and null namespace values to
MailboxConstants.USER_NAMESPACE in MailboxPath(String, String, String)
constructor problematic. Callers should be fully responsible for the
namespace value.
"" should be allowed as a legal namespace prefix, e.g. for a shared namespace.
As for null, is there any good reason for the rewriting?
I see that changing the rewriting of "" and/or null namespace in
MailboxPath would enforce an extensive refactoring.
(4) MailboxPath has three fields: namespace, user and name. We should
make them final and their setters should be removed to avoid
unauthorised or unexpected changes. As far as I can see there are only
a few easily refactorable locations where the setters are invoked.
--
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
