You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Jochen Gazda (Created) (JIRA)" <ji...@apache.org> on 2012/02/21 22:14:48 UTC
[jira] [Created] (MAILBOX-167) Make the namespace handling
consistent and predictable
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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] [Commented] (MAILBOX-167) Make the namespace handling
consistent and predictable
Posted by "Jochen Gazda (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAILBOX-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256260#comment-13256260 ]
Jochen Gazda commented on MAILBOX-167:
--------------------------------------
As there are no protests, I am starting to fulfill all of the above points.
> 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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] [Updated] (MAILBOX-167) Make the namespace handling
consistent and predictable
Posted by "Jochen Gazda (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAILBOX-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jochen Gazda updated MAILBOX-167:
---------------------------------
Assignee: Jochen Gazda (was: Norman Maurer)
Assigning to me.
> 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: Jochen Gazda
>
> (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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] [Commented] (MAILBOX-167) Make the namespace handling
consistent and predictable
Posted by "Jochen Gazda (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAILBOX-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256432#comment-13256432 ]
Jochen Gazda commented on MAILBOX-167:
--------------------------------------
Eric,
> (1) does the rfc describe that the same value must be returned for INBOX?
I do not understand what you mean here: Which RFC? "Returned" when and from which method?
I have created a subtask MAILBOX-175 for the MailboxPath issuses. See my comments there.
> 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: Jochen Gazda
>
> (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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] [Commented] (MAILBOX-167) Make the namespace handling
consistent and predictable
Posted by "Eric Charles (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAILBOX-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256430#comment-13256430 ]
Eric Charles commented on MAILBOX-167:
--------------------------------------
(1) does the rfc describe that the same value must be returned for INBOX?
(2) relying on method rather then constant is a better.
(3) what does the rfc says regarding "" as namespace ? - not sure, but is the caller gives a null, that's not good, and maybe we should runtimeexception, or maybe you have a usecase for null parameters?
(4) +1 for immutability.
> 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: Jochen Gazda
>
> (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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jira] [Commented] (MAILBOX-167) Make the namespace handling
consistent and predictable
Posted by "Eric Charles (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAILBOX-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256554#comment-13256554 ]
Eric Charles commented on MAILBOX-167:
--------------------------------------
>> (1) does the rfc describe that the same value must be returned for INBOX?
> I do not understand what you mean here: Which RFC? "Returned" when and from which method?
> I have created a subtask MAILBOX-175 for the MailboxPath issuses. See my comments there.
mmh, not sure to follow. If your initial point was about null handling, then yes, MAILBOX-175 treats this.
> 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: Jochen Gazda
>
> (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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org