[
https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256491#comment-13256491
]
Jochen Gazda commented on MAILBOX-175:
--------------------------------------
Thanks for your comments, Ioan.
I have completed (1) and (2).
I have chosen not to fulfill (3) as it would result in adding delimiter
attribute to org.apache.james.mailbox.store.mail.model.Mailbox (along with its
persistent implementors) as well.
MailboxPath immutability in combination with no delimiter attribute was the
most difficult to solve in
org.apache.james.mailbox.store.StoreMailboxManager.createMailbox(MailboxPath,
MailboxSession) where the name-ends-with-delimiter check was done and when
positive then setName() was called on a method-external instance of
MailboxPath. I have chosen to throw a MailboxException in that case. There were
too many callers of StoreMailboxManager.createMailbox() to find out in which
ones it can happen.
I will commit together with MAILBOX-167.
> Make the contract of MailboxPath explicit and documented.
> ---------------------------------------------------------
>
> Key: MAILBOX-175
> URL: https://issues.apache.org/jira/browse/MAILBOX-175
> Project: James Mailbox
> Issue Type: Sub-task
> Components: api
> Reporter: Jochen Gazda
> Assignee: Jochen Gazda
>
> Make the contract of org.apache.james.mailbox.model.MailboxPath explicit and
> documented.
> Points to consider:
> (1) Make all attributes immutable - can be done quite easily, no discussion
> expected.
> (2) Null values should be forbidden for at least for name and namespace
> attributes - NullPointerException will be thrown from constructors. A lot of
> client code uses e.g. getName().length(). Clients should be responsible for
> the proper values when creating new instances of MailboxPath.
> (3) Consider adding a delimiter field. Currently delimiter is implicitly
> present in the name value anyway. It would allow:
> (3.1) removing the delimiter parameter from getHierarchyLevels()
> (3.2) adding relativePath(relativeName) method (which is currently done by
> concatenating path segments with bona fide default delimiter in the client
> code).
> (3.3) name attribute could guarrantee that it does not start with delimiter
> (which is sometimes checked in the client code now). For names starting with
> delimiter, either
> (3.3.a) constructors should throw IllegalStateException or
> (3.3.b) the name attribute would be rewritten silently - should perhaps
> be prefered, because of the existing client code.
> (3.4) Currently, there is no delimiter escaping/unescaping (e.g. in parse()
> or getHierarchyLevels()). Should there be any?
--
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
