[
https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256553#comment-13256553
]
Eric Charles commented on MAILBOX-175:
--------------------------------------
>> what does the rfc says regarding "" as namespace ?
> I have no exact reference in my head but Cyrus uses "" for shared namespace.
OK
>> not sure, but is the caller gives a null, that's not good, and maybe we
>> should runtimeexception
> Yes, for both name and namespace attributes, I propose NPE.
I would have thrown IllegalArgumentException
>> or maybe you have a usecase for null parameters?
> I do not have any. Client code should be fixed.
Will you fix it? (when you say 'client', I guess you mean the other james
modules).
> 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: [email protected]
For additional commands, e-mail: [email protected]
