Re: Improved MailboxPath and how to handle the resulting change set
Gentlemen, I have fixed some minor issues in my proposal so please consider my update from 2012-06-28 10:38 CEST (+02:00) https://github.com/gazdahimself/current/commits/MAILBOX-175 Let me introduce my MailboxPath replacement briefly. (1) Firstly, here is the list of issues I consider solved by my proposal: https://issues.apache.org/jira/browse/MAILBOX-175 https://issues.apache.org/jira/browse/MAILBOX-167 https://issues.apache.org/jira/browse/MAILBOX-176 (2) Please read esp. the following post to understand the motivation for this proposal: https://issues.apache.org/jira/browse/MAILBOX-175?focusedCommentId=13260641page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13260641 (3) MailboxPath is replaced by org.apache.james.mailbox.name.MailboxName/DefaultMailboxName. It can be characterized as follows: - umodifiable - it stores only the path segments of a hierarchical name plus hasRoot attribute - offers no way to directly interpret the individual path segments as referring to IMAP namespace, user name, etc. When this kind of interpretation is needed it can be done using MailboxNameResolver - see (5) - knows nothing about delimiter because delimiter matters only to its serialization and deserialization, which is done using MailboxNameCodec - see (6) (4) Except for MailboxName which is to be considered context independent, there is UnresolvedMailboxName. UnresolvedMailboxName is the direct representation of mailbox names coming in and out over the IMAP wire. The meaning of UnresolvedMailboxName may depend on information available in the context of the given IMAP session, such as user name of the current user. Both directions of UnresolvedMailboxName - MailboxName transformation can be done using MailboxNameResolver. (5) MailboxNameResolver/DefaultMailboxNameResolver - except for UnresolvedMailboxName - MailboxName transformations, it defines the layout of the mailbox name hierarchy. It is able to: - tell which part of a given MailboxName is to be interpreted as namespace, user name, ... - tell if the given MailboxName is INBOX of a given user - construct INBOX MailboxName for a given user, etc. It is possible to define alternative hierarchy layouts with new MailboxNameResolver implementations. For instance there are two common interpretations, where INBOX is placed in current IMAP servers: (a) /users/username (b) /users/username/INBOX or /users/username/Inbox DefaultMailboxNameResolver adheres to (a) (6) MailboxNameCodec - my vision was to decouple the delimiter used on the IMAP wire from the delimiter used in mailbox stores, thus avoiding some problems, e.g. related to the lack of delimiter escaping rules in the IMAP RFCs. I thought, with this decoupling one can choose a much more robust MailboxNameCodec (with its own consistent delimiter-escaping rules) for the store than one can for IMAP protocol. If there come an RFC defining IMAP delimiter escaping one day one would only need to switch the MailboxNameCodec for IMAP. With my proposal, it is indeed possible, but not for all mailbox stores. MailDir for instace prescribes the '.' delimiter which IMO the worst one from the commonly used ones. Although my proposal solves quite a long list of issues there remain some points to discuss or improve: (i) DefaultMailboxNameResolver and its usage is by no means elegant (ii) I have changed the schema of JCR, JPA and HBase backend thus making them incompatible with already stored data and I do not provide any transformations from old schemata to the new ones. (iii) There are some compilation errors in mailets project which I was not able to resolve myself. I would ask for assistance when there is a broader consensus about my proposal. Please comment. Best, gazda On Wed, Jun 27, 2012 at 6:55 PM, Jochen Gazda gazdahims...@gmail.com wrote: Gentlemen, I have finally managed it to publish my changeset on GitHub: https://github.com/gazdahimself/current/tree/MAILBOX-175 The state of my brach MAILBOX-175 is in sync with the currently latest svn revision 1354581. My brach MAILBOX-175 can also be diffed against svn revision 1354581 directly on GitHub. Sorry for the delay, I am new to git and I have a new job. Please comment. Best, gazda On Wed, Jun 13, 2012 at 1:51 PM, Ioan Eugen Stan stan.ieu...@gmail.com wrote: HI Gazda, Git is great. Cheers, 2012/6/13 Eric Charles e...@apache.org: Hi Gazda, I'm fine with the push to your personal github. It offers nice ui to show diffs. Thx, Eric On 06/13/2012 10:32 AM, Jochen Gazda wrote: Gentlemen, I could invest about 6 weeks of my time into solving https://issues.apache.org/jira/browse/MAILBOX-175 and https://issues.apache.org/jira/browse/MAILBOX-167. The result is quite a huge and deep changeset. There is a de facto replacement for MailboxPath - so you can imagine, how many classes were changed. Before going too much into details I wanted to agree on a way how my changeset could find its way
Re: Improved MailboxPath and how to handle the resulting change set
Hi Eric, please see inline. Best, gazda On Thu, Jun 28, 2012 at 11:43 AM, Eric Charles e...@apache.org wrote: Looking at the diffs in the order as there are shown on [1]: [1] is now outdated, one can use https://github.com/gazdahimself/current/compare/master...MAILBOX-175 to see the relevant diffs. API 1.- profile noTest on mailbox-integration-tester: ok 2.- LocalAndVirtualMailboxLocatorChain: what's the goal? MailDir is a file system based storage. There is the MaildirLocator interface for mapping of MailboxNames to file system directories and back. There are two basic MaildirLocator implementations: LocalSystemMaildirLocator (maps to /home/user/MailDir) and VirtualMailboxLocator (maps to virtualRoot/domain/user). The third one, LocalAndVirtualMailboxLocatorChain, cobines the two. 3.- MailboxPath is now MailboxName: Path sounded more like folder/subfolder/subfolder. Yes, I agree, that is the case for common English. But there is no single occurence of 'path' in RFC3501. It speaks only about (hierarchical) names. On the other hand, MailboxPath/MailboxName is our internal term which does not map 1:1 to the IMAP hierachical name. We can name it however we want. I am not against going back to MailboxPath. 4.- MailboxNameResolver on MailboxManager You mean that the methods from MailboxNameResolver should better move to MailboxManager? - Well, MailboxManager is defines storage operations, but MailboxNameResolver interprets names. That is something different. Two distinct MailboxNameResolvers are conceivable for a single MailboxManager; see (5) in my previous post ( /users/username vs. /users/username/INBOX ). 5.- MailboxSession has no more PersonalSpace nor UserSpace but a MailboxOwner. The capability to list namespace prefixes has moved from MailboxSession to MailboxNameResolver, which is now a member of MailboxSession. Listing namespace prefixes belongs to the mailbox hierarchy definition entailed in MailboxNameResolver. MailboxOwner is needed to distinguish groups from persons and 'normal' (domain-less) users from virtual users. 6. SubscriptionManager now works with MailboxName and no more with String for mailboxname; OK 7. MailboxACL and MailboxACLCodec: already there before I think Yes. 8. mmh, MailboxPath is still there. Yes, it is still there because there are still references to it from mailets project which I was not able to fix. Otherwise there are only refs in comments which can generally be replaced by MailboxName. 9. MailboxNameSerializer, MailboxNameBuilder, MailboxNameCodec, MailboxNamespaceType, MailboxNameEscaper MailboxNameSerializer belongs to my first attempts. It could be made parent of MailboxNameCodec or replaced altogether. As for MailboxNameCodec cf. (6) of my previous post. MailboxNameBuilder - allows for saving some memory and string-copying when creating a new MailboxName. MailboxNameEscaper - ancillary interface for MailboxNameCodec. MailboxNameCodec implementations mostly differ only in the MailboxNameEscaper they use. 10. LikeSearchPatternEscaper: why deal with JCR, SQL in the API? It is not API, but common to many API consumers. Can you see a better place for it? 11. More and more unit tests... :) Finite verb? JCR, JPA and MEMORY Modules 12. I guess this is the impact of the API changes. HBASE 13. Didn't see any change in the diff SPRING The change in spring-mailbox-jpa.xml is only white space. Reverting. 14. I guess this is the impact of the API changes. STORE 14. I guess this is the impact of the API changes. PROTOCOLS IMAP 15. Sounds logic imap is the only impacted module So very very impressive changes. May I summary them as more typing for domains that ease the reading and implementation of ACL and the overall mailbox? Well, yes, definitely more typing - that is con. Pros are: - Handling mailbox names more reliably - Mailbox names are interpreted on one central place. - Namespace prefixes other than personal are now possible, esp. group folders are possible To be honest, I didn't see well if and how the ACL are applied... :) New in my proposal is only that the ACLs can now be stored in JPA, JCR and HBase in addition to MailDir. They are still not enforced though. https://issues.apache.org/jira/browse/IMAP-358 is still open for that matter. [1] https://github.com/gazdahimself/current/commit/ae75a54400bc7aa93763657a48596d09ec357f98, [1] is now outdated, one can use https://github.com/gazdahimself/current/compare/master...MAILBOX-175 to see the relevant diffs. On 06/27/2012 06:55 PM, Jochen Gazda wrote: Gentlemen, I have finally managed it to publish my changeset on GitHub: https://github.com/gazdahimself/current/tree/MAILBOX-175 The state of my brach MAILBOX-175 is in sync with the currently latest svn revision 1354581. My brach MAILBOX-175 can also be diffed against svn revision 1354581 directly on GitHub. Sorry for the delay, I am new to git and I have a new job. Please comment
Re: Improved MailboxPath and how to handle the resulting change set
Hi Eric, see inline, Best, gazda On Thu, Jun 28, 2012 at 12:53 PM, Eric Charles e...@apache.org wrote: I would like to invite all existing users/developers already working with the mailbox-api to express their thinkings. Yes, please comment! AFAIK, there are a few developers already using the mailbox-api, and this will largely impact their implementation. Yes definitely, please comment! They may have ideas/proposals to take into account at this stage. They may also be worried about your (ii) point: JCR/JPA/HBase schema change. I hope maildir persistence format is not changed, or at least can be transparently upgraded (it shouldn't as it is a defacto standard). Yes, I confirm, that MailDir format stays backward compatible with my proposal. I will off the next 2 weeks. Have a nice holiday! [...] (iii) how is mailet project impacted? There are still references to MailboxPath in mailets project. Unfortunatelly I was not able to grasp the purpose of those refs and I was not able to fix them. Thx again, Eric On 06/28/2012 11:21 AM, Jochen Gazda wrote: Gentlemen, I have fixed some minor issues in my proposal so please consider my update from 2012-06-28 10:38 CEST (+02:00) https://github.com/gazdahimself/current/commits/MAILBOX-175 Let me introduce my MailboxPath replacement briefly. (1) Firstly, here is the list of issues I consider solved by my proposal: https://issues.apache.org/jira/browse/MAILBOX-175 https://issues.apache.org/jira/browse/MAILBOX-167 https://issues.apache.org/jira/browse/MAILBOX-176 (2) Please read esp. the following post to understand the motivation for this proposal: https://issues.apache.org/jira/browse/MAILBOX-175?focusedCommentId=13260641page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13260641 (3) MailboxPath is replaced by org.apache.james.mailbox.name.MailboxName/DefaultMailboxName. It can be characterized as follows: - umodifiable - it stores only the path segments of a hierarchical name plus hasRoot attribute - offers no way to directly interpret the individual path segments as referring to IMAP namespace, user name, etc. When this kind of interpretation is needed it can be done using MailboxNameResolver - see (5) - knows nothing about delimiter because delimiter matters only to its serialization and deserialization, which is done using MailboxNameCodec - see (6) (4) Except for MailboxName which is to be considered context independent, there is UnresolvedMailboxName. UnresolvedMailboxName is the direct representation of mailbox names coming in and out over the IMAP wire. The meaning of UnresolvedMailboxName may depend on information available in the context of the given IMAP session, such as user name of the current user. Both directions of UnresolvedMailboxName- MailboxName transformation can be done using MailboxNameResolver. (5) MailboxNameResolver/DefaultMailboxNameResolver - except for UnresolvedMailboxName- MailboxName transformations, it defines the layout of the mailbox name hierarchy. It is able to: - tell which part of a given MailboxName is to be interpreted as namespace, user name, ... - tell if the given MailboxName is INBOX of a given user - construct INBOX MailboxName for a given user, etc. It is possible to define alternative hierarchy layouts with new MailboxNameResolver implementations. For instance there are two common interpretations, where INBOX is placed in current IMAP servers: (a) /users/username (b) /users/username/INBOX or /users/username/Inbox DefaultMailboxNameResolver adheres to (a) (6) MailboxNameCodec - my vision was to decouple the delimiter used on the IMAP wire from the delimiter used in mailbox stores, thus avoiding some problems, e.g. related to the lack of delimiter escaping rules in the IMAP RFCs. I thought, with this decoupling one can choose a much more robust MailboxNameCodec (with its own consistent delimiter-escaping rules) for the store than one can for IMAP protocol. If there come an RFC defining IMAP delimiter escaping one day one would only need to switch the MailboxNameCodec for IMAP. With my proposal, it is indeed possible, but not for all mailbox stores. MailDir for instace prescribes the '.' delimiter which IMO the worst one from the commonly used ones. Although my proposal solves quite a long list of issues there remain some points to discuss or improve: (i) DefaultMailboxNameResolver and its usage is by no means elegant (ii) I have changed the schema of JCR, JPA and HBase backend thus making them incompatible with already stored data and I do not provide any transformations from old schemata to the new ones. (iii) There are some compilation errors in mailets project which I was not able to resolve myself. I would ask for assistance when there is a broader consensus about my proposal. Please comment. Best, gazda On Wed, Jun 27, 2012 at 6:55 PM, Jochen Gazdagazdahims
Re: Improved MailboxPath and how to handle the resulting change set
Hi Eric,
see inline.
Best,
gazda
On Thu, Jun 28, 2012 at 4:57 PM, Eric Charles e...@apache.org wrote:
On 06/28/2012 04:00 PM, Jochen Gazda wrote:
1.- profile noTest on mailbox-integration-tester: ok
2.- LocalAndVirtualMailboxLocatorChain: what's the goal?
MailDir is a file system based storage. There is the MaildirLocator
interface for mapping of MailboxNames to file system directories and
back. There are two basic MaildirLocator implementations:
LocalSystemMaildirLocator (maps to /home/user/MailDir) and
VirtualMailboxLocator (maps tovirtualRoot/domain/user). The
third one, LocalAndVirtualMailboxLocatorChain, cobines the two.
Ok, got it.
(naming is just not consistent across LocalSystemMaildirLocator /
VirtualMailboxLocator / LocalAndVirtualMailboxLocatorChain (you have Maildir
in the first, not in the others).
3.- MailboxPath is now MailboxName: Path sounded more like
folder/subfolder/subfolder.
Yes, I agree, that is the case for common English. But there is no
single occurence of 'path' in RFC3501. It speaks only about
(hierarchical) names. On the other hand, MailboxPath/MailboxName is
our internal term which does not map 1:1 to the IMAP hierachical name.
We can name it however we want. I am not against going back to
MailboxPath.
The key is 'hierarchical'. I find MailboxPath correctly reflect this point.
With MailboxName, you loose that, and MailboxHierarchicalName is just too
long.
At first sight, I would prefer to revert to MailboxPath.
There are several MailboxName* classes. I will have a look if renaming
them all to MailboxPath* sounds plausible to me.
4.- MailboxNameResolver on MailboxManager
You mean that the methods from MailboxNameResolver should better move
to MailboxManager? - Well, MailboxManager is defines storage
operations, but MailboxNameResolver interprets names. That is
something different. Two distinct MailboxNameResolvers are conceivable
for a single MailboxManager; see (5) in my previous post (
/users/username vs. /users/username/INBOX ).
I was just pointing an additional method MailboxNameResolver
getMailboxNameResolver(); on the MailboxManager interface.
So good as is.
5.- MailboxSession has no more PersonalSpace nor UserSpace but a
MailboxOwner.
The capability to list namespace prefixes has moved from
MailboxSession to MailboxNameResolver, which is now a member of
MailboxSession. Listing namespace prefixes belongs to the mailbox
hierarchy definition entailed in MailboxNameResolver.
OK
MailboxOwner is needed to distinguish groups from persons and 'normal'
(domain-less) users from virtual users.
So you assume a mailbox has always an owner.
Sounds logical, but is it sustained by the RFC?
I have done it that way without thinking of RFC. It is quite practical
to have it like that because one can set reasonable default ACLs which
rely on the notion of owner. Dovecot and Cyrus do that. From
http://wiki.dovecot.org/ACL :
The default ACL for mailboxes is to give the mailbox
owner all permissions and other users none. Mailboxes
in public namespaces don't have owners, so by default
no-one can access them.
To have owners on mailboxes is surely not against the spirit of RFC
4314, which names owner in one of its examples:
For example,
in an implementation that uses UNIX mode bits, the rights swite are
tied, the a right is always granted to the owner of a mailbox and
is never granted to another user.
It would probably be possible to do without mailbox owners but it
seems really impractical to me.
8. mmh, MailboxPath is still there.
Yes, it is still there because there are still references to it from
mailets project which I was not able to fix.
Otherwise there are only refs in comments which can generally be
replaced by MailboxName.
Would it be solved if we revert from MailboxName to MailboxPath?
Yes, perhaps.
9. MailboxNameSerializer, MailboxNameBuilder, MailboxNameCodec,
MailboxNamespaceType, MailboxNameEscaper
MailboxNameSerializer belongs to my first attempts. It could be made
parent of MailboxNameCodec or replaced altogether. As for
MailboxNameCodec cf. (6) of my previous post.
MailboxNameBuilder - allows for saving some memory and string-copying
when creating a new MailboxName.
MailboxNameEscaper - ancillary interface for MailboxNameCodec.
MailboxNameCodec implementations mostly differ only in the
MailboxNameEscaper they use.
I need to read back all this.
Is the goal of all these classes to better support mailbox name charsets and
to build the hierachical mailbox name structure in a efficient way?
No, currently it is not about mailbox name charsets, though
MailboxNameCodec could serve also that purpose.
MailboxNameCodec (and its usual member MailboxNameEscaper) are about
parsing raw string names like INBOX/asf to segment collections like
{INBOX, asf} and serializing those collections back to strings.
Their central task (when decoding) is to recognoze segment
Re: Improved MailboxPath and how to handle the resulting change set
Gentlemen, I have finally managed it to publish my changeset on GitHub: https://github.com/gazdahimself/current/tree/MAILBOX-175 The state of my brach MAILBOX-175 is in sync with the currently latest svn revision 1354581. My brach MAILBOX-175 can also be diffed against svn revision 1354581 directly on GitHub. Sorry for the delay, I am new to git and I have a new job. Please comment. Best, gazda On Wed, Jun 13, 2012 at 1:51 PM, Ioan Eugen Stan stan.ieu...@gmail.com wrote: HI Gazda, Git is great. Cheers, 2012/6/13 Eric Charles e...@apache.org: Hi Gazda, I'm fine with the push to your personal github. It offers nice ui to show diffs. Thx, Eric On 06/13/2012 10:32 AM, Jochen Gazda wrote: Gentlemen, I could invest about 6 weeks of my time into solving https://issues.apache.org/jira/browse/MAILBOX-175 and https://issues.apache.org/jira/browse/MAILBOX-167. The result is quite a huge and deep changeset. There is a de facto replacement for MailboxPath - so you can imagine, how many classes were changed. Before going too much into details I wanted to agree on a way how my changeset could find its way into SVN. The changes should be discussed before they are committed to trunk. But I am not sure what is the best way to share my changes before they are committed to trunk. Would cloning from http://git.apache.org/ and pushing changes to my personal GitHub repo be a viable solution? I am also ready to send my zipped workspace (~30MB) to anybody who wants to have a quick look. Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- Ioan Eugen Stan / http://axemblr.com / Tools for Clouds - 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
How to use git-svn with James
Gentlemen, is there anybody here who has managed it to create a working dir with git-svn? I am trying to apply Git for Apache committers as decribed here http://wiki.apache.org/general/GitAtApache . This is what I am doing: ---8 #!/bin/bash set -x set -e # put your ASF user name here: ASF_USER_NAME= ASF_USER_EMAIL=$asf_user_n...@apache.org PROJECT_NAME=james TRUNK=current # created dummy branches and tags just to exclude the possibility that git-svn needs them BRANCHES=trunk/sandbox/git-branches TAGS=trunk/sandbox/git-tags git clone git://git.apache.org/$PROJECT_NAME.git cd $PROJECT_NAME/.git; wget http://git.apache.org/authors.txt; cd .. git config svn.authorsfile .git/authors.txt # check if your username and email are identical to those in the author file # git config user.name # git config user.email # if they are not identical, set the ASF values locally git config user.name $ASF_USER_NAME git config user.email $ASF_USER_EMAIL git svn init --prefix=origin/ --tags=$TAGS --trunk=$TRUNK --branches=$BRANCHES https://svn.apache.org/repos/asf/$PROJECT_NAME; #git svn init --prefix=origin/ https://svn.apache.org/repos/asf/$PROJECT_NAME/$TRUNK; git svn rebase ---8 It is the last command git svn rebase that fails with this message: Unable to determine upstream SVN information from working tree history Does anybody have an idea what is the problem here? Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: How to use git-svn with James
Thank you for your prompt reply, Eric. I saw you created james/trunk/sandbox/git-branches/, but not sure why. I supposed that --tags and --branches parameters of git svn init may not be left unset and there are no branches and tags in SVN under asf/james. Anyway, it did not help. james/trunk/sandbox/git-* can be removed. I will try some of your proposals. Best, gazda On Thu, Jun 14, 2012 at 11:10 AM, Eric Charles e...@apache.org wrote: Hi Gazda, I saw you created james/trunk/sandbox/git-branches/, but not sure why. The 3 ways I can imagine to work with Apache James git repo are: 1. clone the git repo on your laptop, add a remote to your github, push to the defined remote 2. import your local svn to your github repo (will all the history). 3. remove all .svn folders from your local svn repo, and push this plain source to your github repo. I would have gone for Option 3. which is quite to benefit from the diffs you have to show us without the history. Once OK, a diff (git diff) could be reapplied to the james svn. Option 1. is should also be easy. I already worked with Option 2. (svn to git) for another project, but the import process takes some long time and can give you surprises... Of course, the james multi-project nature will not help you... Thx, Eric On 06/14/2012 10:40 AM, Jochen Gazda wrote: Gentlemen, is there anybody here who has managed it to create a working dir with git-svn? I am trying to apply Git for Apache committers as decribed here http://wiki.apache.org/general/GitAtApache . This is what I am doing: ---8 #!/bin/bash set -x set -e # put your ASF user name here: ASF_USER_NAME= ASF_USER_EMAIL=$asf_user_n...@apache.org PROJECT_NAME=james TRUNK=current # created dummy branches and tags just to exclude the possibility that git-svn needs them BRANCHES=trunk/sandbox/git-branches TAGS=trunk/sandbox/git-tags git clone git://git.apache.org/$PROJECT_NAME.git cd $PROJECT_NAME/.git; wget http://git.apache.org/authors.txt; cd .. git config svn.authorsfile .git/authors.txt # check if your username and email are identical to those in the author file # git config user.name # git config user.email # if they are not identical, set the ASF values locally git config user.name $ASF_USER_NAME git config user.email $ASF_USER_EMAIL git svn init --prefix=origin/ --tags=$TAGS --trunk=$TRUNK --branches=$BRANCHES https://svn.apache.org/repos/asf/$PROJECT_NAME; #git svn init --prefix=origin/ https://svn.apache.org/repos/asf/$PROJECT_NAME/$TRUNK; git svn rebase ---8 It is the last command git svn rebase that fails with this message: Unable to determine upstream SVN information from working tree history Does anybody have an idea what is the problem here? Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles - 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
Improved MailboxPath and how to handle the resulting change set
Gentlemen, I could invest about 6 weeks of my time into solving https://issues.apache.org/jira/browse/MAILBOX-175 and https://issues.apache.org/jira/browse/MAILBOX-167. The result is quite a huge and deep changeset. There is a de facto replacement for MailboxPath - so you can imagine, how many classes were changed. Before going too much into details I wanted to agree on a way how my changeset could find its way into SVN. The changes should be discussed before they are committed to trunk. But I am not sure what is the best way to share my changes before they are committed to trunk. Would cloning from http://git.apache.org/ and pushing changes to my personal GitHub repo be a viable solution? I am also ready to send my zipped workspace (~30MB) to anybody who wants to have a quick look. Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-175) Make the contract of MailboxPath explicit and documented.
[ https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260641#comment-13260641 ] Jochen Gazda commented on MAILBOX-175: -- The ability of the current James code to handle multiple namespaces is much worse than I hoped initially. I carry on the discussion here as MailboxPath is the medium used to transport the namespace information throughout James from IMAP to store backends and back. What I say here for MailboxPath also holds mutatis mutandis for org.apache.james.mailbox.store.mail.model.Mailbox which mirrors MailboxPath attributes. I will abbreviate org.apache.james.mailbox.store.mail.model.Mailbox as model.Mailbox to avoid confusion with mailbox in its common sense. The undelying problem seems to be the following: The exact meaning of the given IMAP mailbox name may strongly depend on its contextual interpretation. This has to do with (i) namespace prefixes and (ii) the special name INBOX. Example: When an IMAP client sends e.g. LIST #private.folder.%, the mailbox name #private.folder does not have any definitive meaning untill it is combined with the name of the current user. Similarly INBOX is the primary mailbox for this user on this server. Not only that there is no central place where this interpretation happens, much worse, one could say that this interpretation does not really happen: namespace prefixes and INBOX names are forwarded to storage backends which blindly (with minor exceptions) take them as parts of the given mailbox'es primary key. Example: when user u1 asks for folder #private.folder.subfolder, all storage backends basically do what the JPA storage does: SELECT mailbox FROM Mailbox mailbox WHERE mailbox.name = :nameParam and mailbox.user= :userParam and mailbox.namespace= :namespaceParam Please note that this makes no harm at present as only the single personal namespace is in play. Now, if we turn multiple namespaces on, look what will happen: Say that other users' mailboxes will be available to the current user u1 under the namespace #otherUsers. Say further that the currently set ACLs grant the user u1 full rights to all folders of the user u2. Now, say u1 wants to pass his folder #private.sales.orders to the user u2 (e.g. because u1 gets retired). To make it happen, u1 moves (i.e. uses IMAP RENAME command) #private.sales.orders to #otherUsers.u2.sales.orders. What will the JPA storage backend do? - rougly the following: UPDATE Mailbox mailbox SET mailbox.name = 'u2.sales.orders' mailbox.user = null mailbox.namespace = '#otherUsers' WHERE mailbox.name = 'sales.orders' and mailbox.user = 'u1' and mailbox.namespace = '#private' Clearly, after this update, u2 will not see sales.orders between his folders. Similar could be demonstrated also for COPY, LIST and probably also other IMAP commands. Here I am trying to propose a strategy how this problem should be addressed. Please comment. First of all there should be a central place where this mailbox name interpretation takes place. As INBOX and namespaces are IMAP notions, they should be interpreted in the IMAP module. Further, MailboxPath should be made absolute in its nature. And finally, the storage backends should play only with such absolute MailboxPaths. What I propose for MailboxPath and model.Mailbox: I still stick with (1) and (2) from my above post. I have abandoned (3), I rather prefer (8). (4) MailboxPath should be absolute, i.e. independent from any contextual interpretation: (4.1) independent from any current folder notion (4.2) independent from any current user notion Any contextual interpretation should take place outside of MailboxPath. Currently I see only IMAP as a place where any interpretation should take place; see (5). (5) A consequence of (4) is that namespace attribute should be removed from MailboxPath. Why: Namespace prefixes may be context dependent. The notion of namespace comes from IMAP. Any context dependency of namespace prefixes should be resolved in the IMAP module. Example: the exact meaning of a MailboxPath located in personal (a.k.a private) namespace depends on the current user. So if an IMAP client authenticated as user u1 is asking for folder #personal.folder.subfolder, the folder name should be resolved by the IMAP module as e.g. users.u1.folder.subfolder. The opposite direction: if a store backend returns users.u1.folder.subfolder to the IMAP module, the IMAP module should transform it to #personal.folder.subfolder if the current user is u1. (6) INBOX: The same holds for the special folder name INBOX: If an IMAP client authenticated as user u1 is asking for folder INBOX, the folder name should be resolved by the IMAP module as e.g. users.u1. (7) Another consequence of (4) is that the user attribute can be removed from MailboxPath. It is not necessary
[jira] [Commented] (MAILBOX-175) Make the contract of MailboxPath explicit and documented.
[ https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13260869#comment-13260869 ] Jochen Gazda commented on MAILBOX-175: -- Ioan, I see only http://www.apps.ietf.org/rfc/rfc2342.html and http://tools.ietf.org/html/rfc3501 esp. http://tools.ietf.org/html/rfc3501#section-5.1.1 as relevant for this discussion. 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
How can I assign an issue to myself in Jira?
Gentlemen, I would like to set myself as Assignee in Jira (e.g. for MAILBOX-167). How can I do that? Am I missing some permission? Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-167) Make the namespace handling consistent and predictable
[
https://issues.apache.org/jira/browse/MAILBOX-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
Re: How can I assign an issue to myself in Jira?
Thank you for your prompt reaction, Stefano. On Wed, Apr 18, 2012 at 9:25 AM, Stefano Bagnara apa...@bago.org wrote: 2012/4/18 Jochen Gazda gazdahims...@gmail.com: Gentlemen, I would like to set myself as Assignee in Jira (e.g. for MAILBOX-167). How can I do that? Am I missing some permission? I added you to the james-developers group. You should now be able to do something more: let me know if it worked. Stefano - 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
[jira] [Updated] (MAILBOX-167) Make the namespace handling consistent and predictable
[
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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (MAILBOX-175) Make the contract of MailboxPath explicit and documented.
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: Task Components: api Reporter: Jochen Gazda Assignee: Norman Maurer 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
[jira] [Assigned] (MAILBOX-175) Make the contract of MailboxPath explicit and documented.
[ https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda reassigned MAILBOX-175: Assignee: Jochen Gazda (was: Norman Maurer) 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: 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
[jira] [Updated] (MAILBOX-175) Make the contract of MailboxPath explicit and documented.
[ https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated MAILBOX-175: - Issue Type: Sub-task (was: Task) Parent: 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
[jira] [Commented] (MAILBOX-167) Make the namespace handling consistent and predictable
[
https://issues.apache.org/jira/browse/MAILBOX-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-175) Make the contract of MailboxPath explicit and documented.
[ https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256435#comment-13256435 ] Jochen Gazda commented on MAILBOX-175: -- Eric, what does the rfc says regarding as namespace ? I have no exact reference in my head but Cyrus uses for shared namespace. 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. or maybe you have a usecase for null parameters? I do not have any. Client code should be fixed. +1 for immutability. 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
[jira] [Commented] (MAILBOX-175) Make the contract of MailboxPath explicit and documented.
[ https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (MAILBOX-175) Make the contract of MailboxPath explicit and documented.
[ https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256567#comment-13256567 ] Jochen Gazda commented on MAILBOX-175: -- 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 OK, be it 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). Yes, I am doing my best now to fix the callers. 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
[jira] [Commented] (MAILBOX-175) Make the contract of MailboxPath explicit and documented.
[ https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256644#comment-13256644 ] Jochen Gazda 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. A small addendum of mine: It is our own business, what we choose as namespace prefixes. Currently we always send NAMESPACE (( .)) NIL NIL to IMAP clients; see NamespaceProcessor.buildPersonalNamespaces(MailboxSession, ImapSession) That means is the prefix for the personal namespace and there are no other namespaces. I.e. we effectively do not support namespaces at the moment. I propose that we abandon sending as a namespace prefix to clients from now on. NettyImapSession.supportMultipleNamespaces() should return true. Then IMAP clients should also cease to send namespaces to us and we can internally declare namespace prefix as invalid. 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
[jira] [Created] (MAILBOX-176) Check the references to MailboxConstants.USER_NAMESPACE
Check the references to MailboxConstants.USER_NAMESPACE --- Key: MAILBOX-176 URL: https://issues.apache.org/jira/browse/MAILBOX-176 Project: James Mailbox Issue Type: Sub-task Reporter: Jochen Gazda Assignee: Jochen Gazda Ensure that the use of MailboxConstants.USER_NAMESPACE is not too blind. Some occurences may come from times when there was no alternative. -- 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
[jira] [Updated] (MAILBOX-176) Check the references to MailboxConstants.USER_NAMESPACE
[ https://issues.apache.org/jira/browse/MAILBOX-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated MAILBOX-176: - Description: Ensure that the use of MailboxConstants.USER_NAMESPACE is not too blind. Some occurences may come from times when there was no alternative. Possible replacements for MailboxConstants.USER_NAMESPACE follow: (a) org.apache.james.mailbox.MailboxSession.getPersonalSpace() (b) if MailboxConstants.USER_NAMESPACE occurs in new MaiboxPath(MailboxConstants.USER_NAMESPACE, otherMailboxPath.getUser(), otherMailboxPath.getName() + ...) then new MaiboxPath(otherMailboxPath.getNamespace(), otherMailboxPath.getUser(), otherMailboxPath.getName() + ...) could be a better choice (c) if MailboxConstants.USER_NAMESPACE occurs in new MaiboxPath(MailboxConstants.USER_NAMESPACE, ..., somePathFromWireOrConfig) then MaiboxPath.parse() could be a better choice. was:Ensure that the use of MailboxConstants.USER_NAMESPACE is not too blind. Some occurences may come from times when there was no alternative. Check the references to MailboxConstants.USER_NAMESPACE --- Key: MAILBOX-176 URL: https://issues.apache.org/jira/browse/MAILBOX-176 Project: James Mailbox Issue Type: Sub-task Reporter: Jochen Gazda Assignee: Jochen Gazda Original Estimate: 0h Remaining Estimate: 0h Ensure that the use of MailboxConstants.USER_NAMESPACE is not too blind. Some occurences may come from times when there was no alternative. Possible replacements for MailboxConstants.USER_NAMESPACE follow: (a) org.apache.james.mailbox.MailboxSession.getPersonalSpace() (b) if MailboxConstants.USER_NAMESPACE occurs in new MaiboxPath(MailboxConstants.USER_NAMESPACE, otherMailboxPath.getUser(), otherMailboxPath.getName() + ...) then new MaiboxPath(otherMailboxPath.getNamespace(), otherMailboxPath.getUser(), otherMailboxPath.getName() + ...) could be a better choice (c) if MailboxConstants.USER_NAMESPACE occurs in new MaiboxPath(MailboxConstants.USER_NAMESPACE, ..., somePathFromWireOrConfig) then MaiboxPath.parse() could be a better choice. -- 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
[jira] [Commented] (PROTOCOLS-95) Protocol dumper for debugging client-server issues
[
https://issues.apache.org/jira/browse/PROTOCOLS-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13255397#comment-13255397
]
Jochen Gazda commented on PROTOCOLS-95:
---
Ioan,
the way how Cyrus IMAP Server achieves the same goal might serve as an
inspiration to us:
{quote}
As a debugging aid, Cyrus IMAP can also log protocol conversations on a
per-user basis. Note that you cannot debug the authentication process using
this, because the protocol logging is only associated with a username and until
a user has been successfully authenticated, the username is unknown.
To enable protocol logging, simply create a directory in /var/lib/imap/log with
the user's name you wish to log. Ensure, of course, that this directory is
writable by the user Cyrus runs as. Cyrus will create files in this directory
with the name of the process ID under which it runs (which changes per
connection due to the forking server model it uses).
{quote}
http://nakedape.cc/info/Cyrus-IMAP-HOWTO/Cyrus-IMAP-HOWTO.html and CTRL-F
Protocol Logging
I personally like the simplicity, how the wire logging can be turned on and off
in Cyrus.
Per-user basis is probably simpler to configure than per-session basis. (How
can sessions be identified?)
Per-user or per-session is a must as the wire-dumping produces quite a lot of
data.
I wonder if this wire logging is not already there in some form in netty? We
are surely not the first ones who need this for a text based protocol.
Protocol dumper for debugging client-server issues
--
Key: PROTOCOLS-95
URL: https://issues.apache.org/jira/browse/PROTOCOLS-95
Project: JAMES Protocols
Issue Type: New Feature
Reporter: Ioan Eugen Stan
Assignee: Norman Maurer
We need a protocol dumper to save the server-client messages maybe in a way
that we can use them to build integration tests.
I'm thinking of mailbox-integration-test script files here that have S: and
C: lines. This way we can easily add integration test cases that match real
cases when we find them.
--
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
Re: ACL support plans
Eric, In my wokspace, I have: (1) changed the pom's in that way that that the protocols-imap code is used instead of apache-james-imap. (2) merged apache-james-imap classes and tests into protocols-imap classes and tests. (3) moved FetchGroupImpl and PartContentDescriptorImpl from protocols-imap to mailbox-api to be able to remove the imap dependency from james-server-mailets. To sum up, I have changes in the following projects: - apache-james - apache-james-mailbox-api - james-server - james-server-mailets - james-server-protocols-imap4 - protocols - protocols-imap As the changes go over several projects, I needed to set the current snapshots as dependendencies in some pom's. May I commit all my changes? Best, gazda On Fri, Mar 16, 2012 at 10:35 AM, Eric Charles e...@apache.org wrote: Hi Gazda, You have to remove in the server's project pom all references to apache-james-imap-* and replace them by the unique protocols-imap (same in app). Doing this, you will have a few compilation failures that should be easily solved by changing the package imports. You can commit for server project, but wait before committing the app project that the 3.0b4 release is done. Thx, Eric On 16/03/12 08:42, Jochen Gazda wrote: Eric, I just wanted to merge the ACL code from apache-james-imap to protocols-imap, but I am still seeing the default build run to use the apache-james-imap code. Is there some simple way how I could tell James to switch to the protocols-imap code? Thank you, gazda On Fri, Mar 9, 2012 at 2:14 PM, Eric Charlese...@apache.org wrote: (snip) I have not started yet. I will have a look at the diffs between protocols-imap and apache-james-imap in the next days and backport all the necessary stuff. Cool! (2) Your tests use mocks and no concrete processor, I think this is the good way to do the unit tests in this case. Hm... You say no concrete processor? Did you not want to say something else? For every test in question, the particular processor of the respective IMAP command IS actually being tested. Perhaps you wanted to say no concrete storage impementation? Oops, yes, I meant 'no concrete mailbox'. Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles - 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 -- eric | http://about.echarles.net | @echarles - 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
Re: ACL support plans
Commited. Further points to consider before closing PROTOCOLS-73 : (4) How will we make the apache-james-imap code obsolete? Do we want to delete it altogether? Or just annotate somehow? (5) There is some site code under the following directories which does not seem to have any counterpart under protocols-imap: apache-james-imap/src/site apache-james-imap/src/reporting-site apache-james-imap-api/src/reporting-site apache-james-imap-message/src/reporting-site apache-james-imap-processor/src/reporting-site Best, gazda On Tue, Apr 17, 2012 at 5:18 PM, Eric Charles e...@apache.org wrote: PS: Also take care to keep the SVN history when moving classes between projects (I use eclipse which does a decent job for that, but I always pay double attention doing those kind of operations). On 04/17/2012 05:09 PM, Eric Charles wrote: Hi Gazda, Thx for sharing the information. (1) and (2) are OK to me, I guess you had fun to find (3) :) (I guess to allow to avoid a dependency between james-server-mailets protocols-api?). Yes, just commit (we do CTR commit then review) assuming you have tested a complete build (app) with a real imap client (such as thunderbird) with a few mails (list mailbox, move mails, search,...). Maybe we could further talk and let evolve (3). Thx, Eric On 04/17/2012 04:48 PM, Jochen Gazda wrote: Eric, In my wokspace, I have: (1) changed the pom's in that way that that the protocols-imap code is used instead of apache-james-imap. (2) merged apache-james-imap classes and tests into protocols-imap classes and tests. (3) moved FetchGroupImpl and PartContentDescriptorImpl from protocols-imap to mailbox-api to be able to remove the imap dependency from james-server-mailets. To sum up, I have changes in the following projects: - apache-james - apache-james-mailbox-api - james-server - james-server-mailets - james-server-protocols-imap4 - protocols - protocols-imap As the changes go over several projects, I needed to set the current snapshots as dependendencies in some pom's. May I commit all my changes? Best, gazda On Fri, Mar 16, 2012 at 10:35 AM, Eric Charlese...@apache.org wrote: Hi Gazda, You have to remove in the server's project pom all references to apache-james-imap-* and replace them by the unique protocols-imap (same in app). Doing this, you will have a few compilation failures that should be easily solved by changing the package imports. You can commit for server project, but wait before committing the app project that the 3.0b4 release is done. Thx, Eric On 16/03/12 08:42, Jochen Gazda wrote: Eric, I just wanted to merge the ACL code from apache-james-imap to protocols-imap, but I am still seeing the default build run to use the apache-james-imap code. Is there some simple way how I could tell James to switch to the protocols-imap code? Thank you, gazda On Fri, Mar 9, 2012 at 2:14 PM, Eric Charlese...@apache.org wrote: (snip) I have not started yet. I will have a look at the diffs between protocols-imap and apache-james-imap in the next days and backport all the necessary stuff. Cool! (2) Your tests use mocks and no concrete processor, I think this is the good way to do the unit tests in this case. Hm... You say no concrete processor? Did you not want to say something else? For every test in question, the particular processor of the respective IMAP command IS actually being tested. Perhaps you wanted to say no concrete storage impementation? Oops, yes, I meant 'no concrete mailbox'. Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles - 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 -- eric | http://about.echarles.net | @echarles - 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 -- eric | http://about.echarles.net | @echarles - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: ACL support plans
Eric, I just wanted to merge the ACL code from apache-james-imap to protocols-imap, but I am still seeing the default build run to use the apache-james-imap code. Is there some simple way how I could tell James to switch to the protocols-imap code? Thank you, gazda On Fri, Mar 9, 2012 at 2:14 PM, Eric Charles e...@apache.org wrote: (snip) I have not started yet. I will have a look at the diffs between protocols-imap and apache-james-imap in the next days and backport all the necessary stuff. Cool! (2) Your tests use mocks and no concrete processor, I think this is the good way to do the unit tests in this case. Hm... You say no concrete processor? Did you not want to say something else? For every test in question, the particular processor of the respective IMAP command IS actually being tested. Perhaps you wanted to say no concrete storage impementation? Oops, yes, I meant 'no concrete mailbox'. Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles - 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
Re: Unable to build HUPA project
Gentlemen, In accordance with what has been said in this thread and with Stefano Bagnara's we should always try to build with the latest available released parent (not even a snapshot), may I commit following two changes? (1) change parent.version from 1.9-SNAPSHOT 1.8.1 in hupa/pom.xml (2) change version.mailbox from 0.4-SNAPSHOT to 0.4 in protocols/pom.xml Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: ACL support plans
Gentlemen, just reposting my old questions. I would like to proceed with https://issues.apache.org/jira/browse/IMAP-358 Enforce rights required to perform different IMAP4rev1 Commands in IMAP processors. (1) Is there something new with protocols-imap vs. apache-james-imap? (2) Tests: Is there a recommended way how to test the enforcement of the individual rights in James? I have written some tests for GETACL, SETACL, LISTRIGHTS, MYRIGHTS and DELETERIGHTS in the apache-james-imap-processor project. All of them are directed towards the respective processors. Could please somebody review esp. the test*Right*() methods in them and tell me if it is sufficient to test the security of other IMAP commands in this way? Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: ACL support plans
Eric, please see inline. (1) I would love to see the current activity in protocols-imap. I had to postpone my contribution on the integration (b4 release and many other stuff), but next week should be a good week for me to work on this. I propose you continue your implementations in protocols-imap (hoping you don't have to backport too much from apache-james-imap such as the tests, and hoping also we can work together on the same codebase, on my side more regarding the integration of the processors in the protocol handler chain). I have not started yet. I will have a look at the diffs between protocols-imap and apache-james-imap in the next days and backport all the necessary stuff. (2) Your tests use mocks and no concrete processor, I think this is the good way to do the unit tests in this case. Hm... You say no concrete processor? Did you not want to say something else? For every test in question, the particular processor of the respective IMAP command IS actually being tested. Perhaps you wanted to say no concrete storage impementation? Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Request for information
Sai, from my experience, I can say that the plain http svn access ceased to work a couple of weeks ago. Try the same URL with https. Best, gazda On Fri, Feb 24, 2012 at 12:22 PM, Saibabu Vallurupalli saibabu.vallurupa...@gmail.com wrote: Hi Eric, I am following the steps given in this page: http://james.apache.org/server/3/dev-build.html to setup development environment. Started checking out the source code from http://svn.apache.org/repos/asf/james/current/ and the checkout is going on since last 7 Hours. Is this still valid svn link? Do you have any better document on setting up development environment? Thanks, Sai On Wed, Feb 15, 2012 at 3:21 PM, Saibabu Vallurupalli saibabu.vallurupa...@gmail.com wrote: Hi Eric, I am still in process. I will get back to once I am ready. Thanks, Sai. On Wed, Feb 15, 2012 at 1:36 PM, Eric Charles e...@apache.org wrote: Hi, Did you succeed to run the latest snapshot? I tried to reproduce the jumping behavior here, but can not. Thx, Eric On 14/02/12 21:08, lclhst wrote: I'd say jumping IMAP folders! :p As it's really something critical that should get fixed before b4 is released. :o I'll provide more.information on the bug tomorrow, but at the moment I cannot get the latest b4 to run. On Feb 14, 2012 8:09 PM, Eric Charlese...@apache.org wrote: Hi Sai, Welcome! The issue trackers are: https://issues.apache.org/jira/browse/JAMEShttps://issues.apache.org/**jira/browse/JAMES https://**issues.apache.org/jira/browse/**JAMEShttps://issues.apache.org/jira/browse/JAMES https://issues.apache.org/jira/browse/MAILBOXhttps://issues.apache.org/**jira/browse/MAILBOX https://**issues.apache.org/jira/browse/**MAILBOXhttps://issues.apache.org/jira/browse/MAILBOX https://issues.apache.org/jira/browse/IMAPhttps://issues.apache.org/**jira/browse/IMAP https://**issues.apache.org/jira/browse/**IMAPhttps://issues.apache.org/jira/browse/IMAP It depends where you would like to begin. We have jumping folder in IMAP, ACL for jpa/jcr/... and many other fun stuff :) Just tell us. Eric On 14/02/12 15:35, Saibabu Vallurupalli wrote: Thanks Stan. I will start setting up environment now. Can you point me to issue tracker? Thanks, Sai On Tue, Feb 14, 2012 at 5:16 AM, Ioan Eugen Stanstan.ieu...@gmail.com ** wrote: Pe 14.02.2012 04:06, Saibabu Vallurupalli a scris: Hi Team, Greetings. I have been using Apache James since last one year and have done an enhancement to Mailbox JPA to Encrypt the message and message header with the help of Eric, Norman and team. Moving forward I would like to do more contributions and also gain more knowledge on Mailbox functionality. Please advise me with next steps. Thank you very much in advance. Thanks, Sai Hello Sai, I can also help you around Mailbox. Just ask when you are in doubt or need things clarified. I think I speak for everybody when I say we are grateful for your contributions. Cheers, -- Ioan Eugen Stan http://ieugen.blogspot.com --**--**--** --**- To unsubscribe, e-mail: server-dev-unsubscribe@james.**apache.org server-dev-**unsubscribe@**james.apache.orgunsubscr...@james.apache.org server-dev-**unsubscr...@james.apache.orgserver-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-help@james.apache.*** ***org server-dev-help@james.**apache**.org http://apache.org server-dev-help@james.**apache.org server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles --** --**- To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org server-dev-**unsubscr...@james.apache.orgserver-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-help@james.apache.org server-dev-help@james.**apache.org server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles --**--**- To unsubscribe, e-mail: server-dev-unsubscribe@james.**apache.orgserver-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-help@james.apache.**orgserver-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
Re: Request for information
Sai, you probably do not need everything, maybe only the mailbox project could be enough for you. But if you are new to james code it might be good for you to see how the things work together. Best, gazda On Fri, Feb 24, 2012 at 2:29 PM, Saibabu Vallurupalli saibabu.vallurupa...@gmail.com wrote: Hi Gazda, I might have explained the issue in a different way. I am able to checkout without any issues. Only problem is it is checking out so much of code and I am wondering if it is really needed for present development. http://svn.apache.org/repos/asf/james/current/ This URL is checking out so much of code. I need only the latest development version to do some development. Thanks, Sai On Fri, Feb 24, 2012 at 8:25 AM, Jochen Gazda gazdahims...@gmail.comwrote: Sai, from my experience, I can say that the plain http svn access ceased to work a couple of weeks ago. Try the same URL with https. Best, gazda On Fri, Feb 24, 2012 at 12:22 PM, Saibabu Vallurupalli saibabu.vallurupa...@gmail.com wrote: Hi Eric, I am following the steps given in this page: http://james.apache.org/server/3/dev-build.html to setup development environment. Started checking out the source code from http://svn.apache.org/repos/asf/james/current/ and the checkout is going on since last 7 Hours. Is this still valid svn link? Do you have any better document on setting up development environment? Thanks, Sai On Wed, Feb 15, 2012 at 3:21 PM, Saibabu Vallurupalli saibabu.vallurupa...@gmail.com wrote: Hi Eric, I am still in process. I will get back to once I am ready. Thanks, Sai. On Wed, Feb 15, 2012 at 1:36 PM, Eric Charles e...@apache.org wrote: Hi, Did you succeed to run the latest snapshot? I tried to reproduce the jumping behavior here, but can not. Thx, Eric On 14/02/12 21:08, lclhst wrote: I'd say jumping IMAP folders! :p As it's really something critical that should get fixed before b4 is released. :o I'll provide more.information on the bug tomorrow, but at the moment I cannot get the latest b4 to run. On Feb 14, 2012 8:09 PM, Eric Charlese...@apache.org wrote: Hi Sai, Welcome! The issue trackers are: https://issues.apache.org/jira/browse/JAMES https://issues.apache.org/**jira/browse/JAMES https://**issues.apache.org/jira/browse/**JAMES https://issues.apache.org/jira/browse/JAMES https://issues.apache.org/jira/browse/MAILBOX https://issues.apache.org/**jira/browse/MAILBOX https://**issues.apache.org/jira/browse/**MAILBOX https://issues.apache.org/jira/browse/MAILBOX https://issues.apache.org/jira/browse/IMAP https://issues.apache.org/**jira/browse/IMAP https://**issues.apache.org/jira/browse/**IMAP https://issues.apache.org/jira/browse/IMAP It depends where you would like to begin. We have jumping folder in IMAP, ACL for jpa/jcr/... and many other fun stuff :) Just tell us. Eric On 14/02/12 15:35, Saibabu Vallurupalli wrote: Thanks Stan. I will start setting up environment now. Can you point me to issue tracker? Thanks, Sai On Tue, Feb 14, 2012 at 5:16 AM, Ioan Eugen Stan stan.ieu...@gmail.com ** wrote: Pe 14.02.2012 04:06, Saibabu Vallurupalli a scris: Hi Team, Greetings. I have been using Apache James since last one year and have done an enhancement to Mailbox JPA to Encrypt the message and message header with the help of Eric, Norman and team. Moving forward I would like to do more contributions and also gain more knowledge on Mailbox functionality. Please advise me with next steps. Thank you very much in advance. Thanks, Sai Hello Sai, I can also help you around Mailbox. Just ask when you are in doubt or need things clarified. I think I speak for everybody when I say we are grateful for your contributions. Cheers, -- Ioan Eugen Stan http://ieugen.blogspot.com --**--**--** --**- To unsubscribe, e-mail: server-dev-unsubscribe@james.** apache.org server-dev-**unsubscribe@**james.apache.org unsubscr...@james.apache.org server-dev-**unsubscr...@james.apache.org server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-help@james.apache. *** ***org server-dev-help@james.**apache**.org http://apache.org server-dev-help@james.**apache.org server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles --** --**- To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org server-dev-**unsubscr...@james.apache.org server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-help@james.apache. org server-dev-help@james.**apache.org server-dev-h...@james.apache.org
Re: [VOTE] Release Apache James Mailbox 0.4
[ ] +0 insufficient insight Just a single point: there is [MAILBOX-154] - Add ACL support in release notes. It could cause a false impression that mailbox 0.4 is going to support ACLs which is not the case. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [VOTE][2nd] Release Apache James jSieve 0.5
[ ] +0 insufficient insight Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: How to build James from trunk
Gentlemen, I still have problems to understand what is normal and what is not normal with maven and James. (1) From what goes on on this mailing list I have understood that James Components live their lives quite independently from each other. So, it is normal that in some development phases component1 has version 0.2 in its pom.xml but in other modules' poms component1 version 0.1 is still referenced. (Am I right so far?) Note that in this example the referenced version 0.1 is lover than the trunk version 0.2. There are two principal kinds of references in Maven poms: (i) dependency and (ii) parent. As for dependencies, it is perfectly reasonable for me that component2 depends on component1 version 0.1, whereby there is already the version 0.2 of component1 in the trunk. But as for parent references I am asking myself what can be the reason for distinct versions in the parent's project.version and its child's project.parent.version? Here is an example from the current trunk: apache-jsieve has version 0.6-SNAPSHOT in its pom, but 0.5-SNAPSHOT is referenced in apache-jsieve-assemble's pom as its parent. Both m2e and mvn install complain about that. When I replace 0.5-SNAPSHOT in apache-jsieve-assemble's pom with 0.6-SNAPSHOT it works. Is it a bug? apache-james-mailbox referencing james-project 1.8.1-SNAPSHOT as its parent is another example. Why does it not reference james-project 1.8.2-SNAPSHOT? Generally, which are there situations in which parent reference version lower than parent trunk version make sense? (2) In (1) I spoke about the case when referenced version is lover than the trunk version. Here I am asking about the opposite: hupa-parent references james-project 1.9-SNAPSHOT as its parent but the version of james-project in the trunk is 1.8.2-SNAPSHOT. This cannot be OK, can it? hupa-parent should be fixed to reference james-project 1.8.2-SNAPSHOT as its parent, should it not? (3) Generally, is the following sequence always expected to work and if it does not, is it a reason to file a bug in Jira? rm -Rf $HOME/.m2/repository cd james/current svn update mvn clean install -DskipTests Best, gazda On Fri, Jan 13, 2012 at 10:23 AM, Jochen Gazda gazdahims...@gmail.com wrote: Thanks for the tips, Eric and Ioan. Maven seems to work as expected now. Gazda On Thu, Jan 12, 2012 at 8:13 AM, Ioan Eugen Stan stan.ieu...@gmail.com wrote: Pe 11.01.2012 21:40, Eric Charles a scris: Hi Jochen, Your settings.xml seems ok. 'mvn package' (or even compile) from a toplevel should take the snapshots from your sources even if not installed. I usually invoke 'mvn clean install' in case of weird behaviour. Can you now compile? Thx, Eric Also, sometimes, it helps to delete all downloaded files from your maven local repository. -- Ioan Eugen Stan http://ieugen.blogspot.com - 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
[jira] [Resolved] (HUPA-84) Make web.xml dtd compliant
[ https://issues.apache.org/jira/browse/HUPA-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda resolved HUPA-84. -- Resolution: Fixed Make web.xml dtd compliant -- Key: HUPA-84 URL: https://issues.apache.org/jira/browse/HUPA-84 Project: JAMES Hupa Issue Type: Bug Components: client Reporter: Jochen Gazda Assignee: Norman Maurer Attachments: HUPA-84-patch.txt The patch follows -- 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
[jira] [Closed] (HUPA-84) Make web.xml dtd compliant
[ https://issues.apache.org/jira/browse/HUPA-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda closed HUPA-84. Make web.xml dtd compliant -- Key: HUPA-84 URL: https://issues.apache.org/jira/browse/HUPA-84 Project: JAMES Hupa Issue Type: Bug Components: client Reporter: Jochen Gazda Assignee: Norman Maurer Attachments: HUPA-84-patch.txt The patch follows -- 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
Make the namespace handling consistent and predictable
Gentlemen,
On the way to usable group folders and ACL, I found that namespaces
are not handled consistently.
(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.
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.
Best,
gazda
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
Can the support for missing ACL commands be committed now?
Eric, may I commit now? Or should I do it after the upcoming mailbox release? I have changes in: - apache-james-imap-api - apache-james-imap-message - apache-james-imap-processor - apache-james-mailbox-api - apache-james-mailbox-store Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: How to build James from trunk
Thank your replies, Stefano and Eric. See inline. Best, gazda On Tue, Feb 21, 2012 at 3:31 PM, Stefano Bagnara apa...@bago.org wrote: 2012/2/21 Jochen Gazda gazdahims...@gmail.com: (1) [] But as for parent references I am asking myself what can be the reason for distinct versions in the parent's project.version and its child's project.parent.version? Here is an example from the current trunk: apache-jsieve has version 0.6-SNAPSHOT in its pom, but 0.5-SNAPSHOT is referenced in apache-jsieve-assemble's pom as its parent. Both m2e and mvn install complain about that. When I replace 0.5-SNAPSHOT in apache-jsieve-assemble's pom with 0.6-SNAPSHOT it works. Is it a bug? IMO ti does not make sense and it is a bug. I guess the issue is related to the use of parent module in a subfolder pattern, that is much more difficult to deal with. Eric seems to work on jsieve at the moment. apache-jsieve-assemble module was commented out from its parent and it does not harm my builds now. apache-james-mailbox referencing james-project 1.8.1-SNAPSHOT as its parent is another example. Why does it not reference james-project 1.8.2-SNAPSHOT? Maybe simply because the last time we worked on mailbox we only had 1.8.1-SNAPSHOT and the parent moved forward in the mean time. This is not a big issue, but you can move mailvox to 1.8.1 final or to 1.8.2-SNAPSHOT if it helps. I think we can forget about this one too. There is 1.8.1 at present in the trunk which works for me. And yesterday, when I tried to compile it was 1.9-SNAPSHOT and not 1.8.1-SNAPSHOT as I told you. Sorry. Generally, which are there situations in which parent reference version lower than parent trunk version make sense? It simply happens because we don't start upgrading every project pom when we move the parent forward but we only upgrade them when we need a release. Otherwise we should always try to build with the latest available released parent (not even a snapshot). Why should we always try to build with the latest available released parent? And who is we here? Did you mean (a) we = developers building James to test our own changes or is it (b) we = developers building a release for the public? At the moment I can identify myself with (a): I am trying to find a way how to effectively test my own changes in a freshly built James instance. I will consider what you recommend at the bottom: mvn clean package mvn install for each project (in the right order, so to not depend on only snapshot repositories) (2) In (1) I spoke about the case when referenced version is lover than the trunk version. Here I am asking about the opposite: hupa-parent references james-project 1.9-SNAPSHOT as its parent but the version of james-project in the trunk is 1.8.2-SNAPSHOT. This cannot be OK, can it? Well, when you work with snapshot everything can be right or wrong. If you release 1.8 then you automatically create 1.9-SNAPSHOT.. after a while you decide to release 1.9-SNAPSHOT as 1.8.1 and this will move you to 1.8.2-SNAPSHOT. As they are snapshots it is not so bad. hupa-parent should be fixed to reference james-project 1.8.2-SNAPSHOT as its parent, should it not? BTW, it would be better to point to 1.8.1 because it probably doesn't need anymore to point to a snapshot for the parent. (3) Generally, is the following sequence always expected to work and if it does not, is it a reason to file a bug in Jira? rm -Rf $HOME/.m2/repository cd james/current svn update mvn clean install -DskipTests I often found problematic to run a single pass mvn clean install but runinng the mvn clean package mvn install for each project (in the right order, so to not depend on only snapshot repositories) is expected to work and if it doesn't work we should probably fix something. Stefano - 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
[jira] [Updated] (IMAP-359) Implement missing ACL commands SETACL, LISTRIGHTS, MYRIGHTS and DELETERIGHTS
[ https://issues.apache.org/jira/browse/IMAP-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated IMAP-359: -- Summary: Implement missing ACL commands SETACL, LISTRIGHTS, MYRIGHTS and DELETERIGHTS (was: Implement missing ACL commands SETACL, LISTRIGHTS and MYRIGHTS) Implement missing ACL commands SETACL, LISTRIGHTS, MYRIGHTS and DELETERIGHTS Key: IMAP-359 URL: https://issues.apache.org/jira/browse/IMAP-359 Project: JAMES Imap Issue Type: Task Components: Processor Reporter: Jochen Gazda GETACL implemented already -- 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
Re: Make the namespace handling consistent and predictable
I have filled this in Jira under
https://issues.apache.org/jira/browse/MAILBOX-167
On Tue, Feb 21, 2012 at 8:31 PM, Jochen Gazda gazdahims...@gmail.com wrote:
Gentlemen,
On the way to usable group folders and ACL, I found that namespaces
are not handled consistently.
(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.
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.
Best,
gazda
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (IMAP-359) Implement missing ACL commands SETACL, LISTRIGHTS, MYRIGHTS and DELETERIGHTS
[ https://issues.apache.org/jira/browse/IMAP-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212961#comment-13212961 ] Jochen Gazda commented on IMAP-359: --- The changes were committed but I am leaving this open because of MAILBOX-167. I left ACL disabled in spring-server.xml for the same reason. Implement missing ACL commands SETACL, LISTRIGHTS, MYRIGHTS and DELETERIGHTS Key: IMAP-359 URL: https://issues.apache.org/jira/browse/IMAP-359 Project: JAMES Imap Issue Type: Task Components: Processor Reporter: Jochen Gazda GETACL implemented already -- 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
[jira] [Closed] (MAILBOX-160) Mapping of ACL to to READ-WRITE and READ-ONLY response codes
[ https://issues.apache.org/jira/browse/MAILBOX-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda closed MAILBOX-160. Resolution: Fixed Mapping of ACL to to READ-WRITE and READ-ONLY response codes Key: MAILBOX-160 URL: https://issues.apache.org/jira/browse/MAILBOX-160 Project: James Mailbox Issue Type: Improvement Components: store Reporter: Jochen Gazda Assignee: Norman Maurer Attachments: MAILBOX-160-patch.txt Patch follows -- 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
[jira] [Closed] (MAILBOX-157) Review the ACL persistence in MaildirFolder
[ https://issues.apache.org/jira/browse/MAILBOX-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda closed MAILBOX-157. Resolution: Fixed Review the ACL persistence in MaildirFolder --- Key: MAILBOX-157 URL: https://issues.apache.org/jira/browse/MAILBOX-157 Project: James Mailbox Issue Type: Task Components: maildir mailbox Reporter: Jochen Gazda Assignee: Norman Maurer There are two FIXMEs in org.apache.james.mailbox.maildir.MaildirFolder. Further the ACL persistence should be tested. -- 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
ACL support plans
Gentlemen, In the next weeks, I would like to proceed with https://issues.apache.org/jira/browse/IMAP-358 Enforce rights required to perform different IMAP4rev1 Commands in IMAP processors. Just two questions: (1) Is it still OK if I further work under apache-james-imap and not under protocols-imap? Is there a rough estimate when will apache-james-imap become obsolete? (2) Tests: Is there a recommended way how to test the enforcement of the individual rights in James? I have written some tests for GETACL, SETACL, LISTRIGHTS, MYRIGHTS and DELETERIGHTS in the apache-james-imap-processor project. All of them are directed towards the respective processors. Could please somebody review esp. the test*Right*() methods in them and tell me if it is sufficient to test the security of other IMAP commands in this way? Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (HUPA-84) Make web.xml dtd compliant
Make web.xml dtd compliant -- Key: HUPA-84 URL: https://issues.apache.org/jira/browse/HUPA-84 Project: JAMES Hupa Issue Type: Bug Components: client Reporter: Jochen Gazda Assignee: Norman Maurer The patch follows -- 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
[jira] [Updated] (HUPA-84) Make web.xml dtd compliant
[ https://issues.apache.org/jira/browse/HUPA-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated HUPA-84: - Attachment: HUPA-84-patch.txt The patch should be applied against /hupa-client/src/main/webapp/WEB-INF/web.xml It only reorders servlet and servlet-mapping elements to make the web.xml DTD compliant. Make web.xml dtd compliant -- Key: HUPA-84 URL: https://issues.apache.org/jira/browse/HUPA-84 Project: JAMES Hupa Issue Type: Bug Components: client Reporter: Jochen Gazda Assignee: Norman Maurer Attachments: HUPA-84-patch.txt The patch follows -- 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
patch for IMAP-359 ready but blocked by MAILBOX-160
Gentlemen, could please somebody review and commit the https://issues.apache.org/jira/browse/MAILBOX-160 patch so that I can diff for https://issues.apache.org/jira/browse/IMAP-359? Thank you, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (MAILBOX-161) ACL persistence in HBaseMailbox
ACL persistence in HBaseMailbox --- Key: MAILBOX-161 URL: https://issues.apache.org/jira/browse/MAILBOX-161 Project: James Mailbox Issue Type: Task Components: hbase Reporter: Jochen Gazda getACL() and setACL(MailboxACL) method stubs should be filled with code. -- 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
[jira] [Created] (MAILBOX-163) ACL persistence in JPAMailbox
ACL persistence in JPAMailbox - Key: MAILBOX-163 URL: https://issues.apache.org/jira/browse/MAILBOX-163 Project: James Mailbox Issue Type: Task Components: jpa mailbox Reporter: Jochen Gazda Assignee: Norman Maurer getACL() and setACL(MailboxACL) method stubs should be filled with code. -- 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
[jira] [Created] (MAILBOX-162) ACL persistence in JCRMailbox
ACL persistence in JCRMailbox - Key: MAILBOX-162 URL: https://issues.apache.org/jira/browse/MAILBOX-162 Project: James Mailbox Issue Type: Task Components: jcr mailbox Reporter: Jochen Gazda Assignee: Norman Maurer getACL() and setACL(MailboxACL) method stubs should be filled with code. -- 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
[jira] [Created] (IMAP-358) Enforce rights required to perform different IMAP4rev1 Commands in IMAP processors
Enforce rights required to perform different IMAP4rev1 Commands in IMAP processors -- Key: IMAP-358 URL: https://issues.apache.org/jira/browse/IMAP-358 Project: JAMES Imap Issue Type: Improvement Components: Processor Reporter: Jochen Gazda RFC 4314 section 4. Write tests. -- 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
[jira] [Created] (MAILBOX-164) MailboxACLUpdated event should be fired and litstened to.
MailboxACLUpdated event should be fired and litstened to. - Key: MAILBOX-164 URL: https://issues.apache.org/jira/browse/MAILBOX-164 Project: James Mailbox Issue Type: Task Components: api Reporter: Jochen Gazda Assignee: Norman Maurer See org.apache.james.mailbox.MailboxListener.MailboxACLUpdated -- 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
[jira] [Created] (IMAP-359) Implement missing ACL commands SETACL, LISTRIGHTS and MYRIGHTS
Implement missing ACL commands SETACL, LISTRIGHTS and MYRIGHTS -- Key: IMAP-359 URL: https://issues.apache.org/jira/browse/IMAP-359 Project: JAMES Imap Issue Type: Task Components: Processor Reporter: Jochen Gazda GETACL implemented already -- 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
[jira] [Commented] (IMAP-351) ACL Support
[ https://issues.apache.org/jira/browse/IMAP-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13205302#comment-13205302 ] Jochen Gazda commented on IMAP-351: --- Just to sum up the state of the tasks mentioned in the original post: (1) I have put some FIXMEs and TODOs in the patch where somebody experienced should please have a look. See IMAP-354, IMAP-355, IMAP-356, MAILBOX-156, MAILBOX-157 and MAILBOX-158 (2) ACL getter and setter stubs should be filled in Mailbox implementations. New tests should be added for those getters and setters. See MAILBOX-161, MAILBOX-162, MAILBOX-163 and MAILBOX-158 (3) Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes, see RFC 4314 section 5.2. See MAILBOX-160 (4) Enforce rights required to perform different IMAP4rev1 Commands in IMAP processors, see RFC 4314 section 4. Write tests. See IMAP-358 (5) MailboxACLUpdated event should be fired and litstened to. See MAILBOX-164 (6) A new one: IMAP-359 Implement missing ACL commands SETACL, LISTRIGHTS and MYRIGHTS ACL Support --- Key: IMAP-351 URL: https://issues.apache.org/jira/browse/IMAP-351 Project: JAMES Imap Issue Type: New Feature Components: JCR Mailbox, JPA Mailbox, Mailbox, Maildir Mailbox, Parser, Processor, Protocol Affects Versions: 0.3 Reporter: Jochen Gazda Labels: ACL, IMAP Fix For: 0.3 Attachments: IMAP-GETACL.txt, ImapGetACLTest.java Original Estimate: 672h Remaining Estimate: 672h Support for RFC 4314 IMAP4 Access Control List (ACL) Extension -- 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
Re: Are flags implicitly shared in James mailboxes?
@Norman: as we store the flags with each message I guess we also would share all flags modifications. Is this not allowed as per rfc ? RFC 4314 If the ACL server implements some flags as shared for a mailbox... implies that it is OK to share *some* flags and I was not able to find any explicit statement that is illegal to share *all* flags. So, if we share all flags, it is probably RFC compliant. One more example how it is done by others: Oracle Communications Suite can be configured either so that all flags are shared or so that all flags are private: store.privatesharedfolders.shareflags If disabled (0), users of a shared folder have their own set of flags (for example, seen, deleted, and so on) for messages in that folder. If enabled (1), a single set of flags is shared between all users of each shared folder. See: https://wikis.oracle.com/display/CommSuite/Managing+Shared+Folders @Eric: I didn't see either in the code the notion of R/RW flags, so we should conclude it's not there at all. READ-WRITE and READ-ONLY response codes are sent by James. The actual value comes from StoreMessageManager.isWriteable(MailboxSession) which returns always true. This is where I am going to intervene with my ACL mapping. I read RFC4314#5.2, but I'm not sure to get it right: is shared multiuser access mandatory to give access to another user to my mailbox, or is it an option. In other words is shared multiuser access synonym to acl-based access ? I also had problems to digest that section. It says that server [= impementation] MAY allow shared multiuser access [...] if [...] users have proper access rights. I believe it means that shared multiuser access is synonymous to acl-based access. I propose that in the mapping of ACL to READ-WRITE and READ-ONLY response codes I will use a new method getSharedPermanentFlags(MailboxSession) in StoreMessageManager which will just return this.getPermanentFlags(session), i.e all flags are shared, in accordance with what Norman said. This solution will allow us to make the sharedness of individual flags configurable later in the future. Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (MAILBOX-160) Mapping of ACL to to READ-WRITE and READ-ONLY response codes
Mapping of ACL to to READ-WRITE and READ-ONLY response codes Key: MAILBOX-160 URL: https://issues.apache.org/jira/browse/MAILBOX-160 Project: James Mailbox Issue Type: Improvement Components: store Reporter: Jochen Gazda Assignee: Norman Maurer Patch follows -- 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
[jira] [Updated] (MAILBOX-160) Mapping of ACL to to READ-WRITE and READ-ONLY response codes
[ https://issues.apache.org/jira/browse/MAILBOX-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated MAILBOX-160: - Attachment: MAILBOX-160-patch.txt The patch applies against current project. Mapping of ACL to to READ-WRITE and READ-ONLY response codes Key: MAILBOX-160 URL: https://issues.apache.org/jira/browse/MAILBOX-160 Project: James Mailbox Issue Type: Improvement Components: store Reporter: Jochen Gazda Assignee: Norman Maurer Attachments: MAILBOX-160-patch.txt Patch follows -- 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
Are flags implicitly shared in James mailboxes?
Gentlemen, I am working on the mapping of ACL to to READ-WRITE and READ-ONLY response codes. The mapping is defined in RFC 4314 section 5.2. The definition uses the term shared flags: If the ACL server implements some flags as shared for a mailbox (i.e., the ACL for the mailbox MAY be set up so that changes to those flags are visible to another user), I tried to search through the Mailbox code how this is supported. The only relevant locations seem to be the getPermanentFlags(MailboxSession) methods in StoreMessageManager hierarchy. My conclusion is, that there is no possibility to configure some flags as shared or not shared. Am I right? All flags are probably either implicitly shared or implicitly not shared but I am not able to tell which one is the case. So, my question is: If we allow multiple users to access a single mailbox (which we do not allow at the moment), would the flag modifications performed by one user be visible to other users? AFAIK in Cyrus IMAP server, the only flag which can be configured as shared for a given mailbox is the SEEN flag, see http://linux.die.net/man/1/cyradm Best, gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-156) Decide where should GroupMembershipResolver interface be located
[ https://issues.apache.org/jira/browse/MAILBOX-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13203493#comment-13203493 ] Jochen Gazda commented on MAILBOX-156: -- Eric, GroupMembershipResolver will be called by ACL related classes, but its implementations will probably go far behind ACL. I see group memberships as something closely related to user management. GroupMembershipResolvers will probably be implemented together with (or maybe within?) UserRepositories (for LDAP, JPA, ...), so the GroupMembershipResolver interface should maybe go to org.apache.james.user? Anyway, here is my proposal for the javadoc sentence: An interface for querying group memberships. Best, gazda Decide where should GroupMembershipResolver interface be located Key: MAILBOX-156 URL: https://issues.apache.org/jira/browse/MAILBOX-156 Project: James Mailbox Issue Type: Task Components: api Reporter: Jochen Gazda Assignee: Norman Maurer Currently the GroupMembershipResolver is located within org.apache.james.mailbox.MailboxACLResolver. Please move it to an appropriate place or leave it where it is now. Then remove the FIXME tag. -- 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
[jira] [Commented] (MAILBOX-157) Review the ACL persistence in MaildirFolder
[ https://issues.apache.org/jira/browse/MAILBOX-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13203498#comment-13203498 ] Jochen Gazda commented on MAILBOX-157: -- Eric, I am OK with that locking, but I know little about possible consequences (performance, deadlocks, ...). I tried to implement it analogously to other persistence methods in MaildirFolder. Best, gazda Review the ACL persistence in MaildirFolder --- Key: MAILBOX-157 URL: https://issues.apache.org/jira/browse/MAILBOX-157 Project: James Mailbox Issue Type: Task Components: maildir mailbox Reporter: Jochen Gazda Assignee: Norman Maurer There are two FIXMEs in org.apache.james.mailbox.maildir.MaildirFolder. Further the ACL persistence should be tested. -- 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
[jira] [Updated] (IMAP-354) Move all CharsetUtil.encodeModifiedUTF7 invocations to ImapResponseComposer
[ https://issues.apache.org/jira/browse/IMAP-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated IMAP-354: -- Attachment: IMAP-354-patch.txt The patch centralizes the mailbox name encoding to org.apache.james.imap.encode.base.ImapResponseComposerImpl.mailbox(String). All CharsetUtil.encodeModifiedUTF7() callers were modified to use ImapResponseComposer.mailbox(). Move all CharsetUtil.encodeModifiedUTF7 invocations to ImapResponseComposer --- Key: IMAP-354 URL: https://issues.apache.org/jira/browse/IMAP-354 Project: JAMES Imap Issue Type: Improvement Reporter: Jochen Gazda Priority: Minor Attachments: IMAP-354-patch.txt All CharsetUtil.encodeModifiedUTF7 invocations should be moved to org.apache.james.imap.encode.ImapResponseComposer analogically to org.apache.james.imap.decode.ImapRequestLineReader.mailbox() -- 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
[jira] [Commented] (IMAP-354) Move all CharsetUtil.encodeModifiedUTF7 invocations to ImapResponseComposer
[ https://issues.apache.org/jira/browse/IMAP-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13202334#comment-13202334 ] Jochen Gazda commented on IMAP-354: --- The patch needs to be applied against the root directory of apache-james-imap-message project. Move all CharsetUtil.encodeModifiedUTF7 invocations to ImapResponseComposer --- Key: IMAP-354 URL: https://issues.apache.org/jira/browse/IMAP-354 Project: JAMES Imap Issue Type: Improvement Reporter: Jochen Gazda Priority: Minor Attachments: IMAP-354-patch.txt All CharsetUtil.encodeModifiedUTF7 invocations should be moved to org.apache.james.imap.encode.ImapResponseComposer analogically to org.apache.james.imap.decode.ImapRequestLineReader.mailbox() -- 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
[jira] [Created] (IMAP-355) Improve human readable messages in GetACLProcessor
Improve human readable messages in GetACLProcessor -- Key: IMAP-355 URL: https://issues.apache.org/jira/browse/IMAP-355 Project: JAMES Imap Issue Type: Improvement Components: Processor Reporter: Jochen Gazda The patch follows. -- 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
[jira] [Updated] (IMAP-355) Improve human readable messages in GetACLProcessor
[ https://issues.apache.org/jira/browse/IMAP-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated IMAP-355: -- Attachment: IMAP-355-patch.txt The patch adds one ACL-specific human readable text. As the text contains parameters, org.apache.james.imap.encode.main.DefaultLocalizer was modified to use MessageFormat and HumanReadableText.getParameters(). Improve human readable messages in GetACLProcessor -- Key: IMAP-355 URL: https://issues.apache.org/jira/browse/IMAP-355 Project: JAMES Imap Issue Type: Improvement Components: Processor Reporter: Jochen Gazda Attachments: IMAP-355-patch.txt The patch follows. -- 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
[jira] [Updated] (IMAP-355) Improve human readable messages in GetACLProcessor
[ https://issues.apache.org/jira/browse/IMAP-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated IMAP-355: -- Attachment: (was: IMAP-355-patch.txt) Improve human readable messages in GetACLProcessor -- Key: IMAP-355 URL: https://issues.apache.org/jira/browse/IMAP-355 Project: JAMES Imap Issue Type: Improvement Components: Processor Reporter: Jochen Gazda Attachments: IMAP-355.1-patch.txt The patch follows. -- 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
[jira] [Updated] (IMAP-354) Move all CharsetUtil.encodeModifiedUTF7 invocations to ImapResponseComposer
[ https://issues.apache.org/jira/browse/IMAP-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated IMAP-354: -- Attachment: (was: IMAP-354-patch.txt) Move all CharsetUtil.encodeModifiedUTF7 invocations to ImapResponseComposer --- Key: IMAP-354 URL: https://issues.apache.org/jira/browse/IMAP-354 Project: JAMES Imap Issue Type: Improvement Reporter: Jochen Gazda Priority: Minor Attachments: IMAP-354.1-patch.txt All CharsetUtil.encodeModifiedUTF7 invocations should be moved to org.apache.james.imap.encode.ImapResponseComposer analogically to org.apache.james.imap.decode.ImapRequestLineReader.mailbox() -- 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
[jira] [Updated] (IMAP-355) Improve human readable messages in GetACLProcessor
[ https://issues.apache.org/jira/browse/IMAP-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated IMAP-355: -- Attachment: IMAP-355.1-patch.txt Improved patch. Apply against apache-james-imap project Improve human readable messages in GetACLProcessor -- Key: IMAP-355 URL: https://issues.apache.org/jira/browse/IMAP-355 Project: JAMES Imap Issue Type: Improvement Components: Processor Reporter: Jochen Gazda Attachments: IMAP-355.1-patch.txt The patch follows. -- 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
[jira] [Created] (IMAP-356) Review ACL related changes in MailboxEventAnalyserTest remove the FIXME tag
Review ACL related changes in MailboxEventAnalyserTest remove the FIXME tag
---
Key: IMAP-356
URL: https://issues.apache.org/jira/browse/IMAP-356
Project: JAMES Imap
Issue Type: Task
Components: Processor
Reporter: Jochen Gazda
There is an anonymous MessageManager returned from
org.apache.james.imap.processor.base.MailboxEventAnalyserTest.mockManager.new
MailboxManager() {...}.getMailbox(MailboxPath, MailboxSession). Somebody should
please review if it is OK that hasRight of this MessageManager always returns
true. The FIXME tag on line 301 can then be removed.
--
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
[jira] [Created] (MAILBOX-156) Decide where should GroupMembershipResolver interface be located
Decide where should GroupMembershipResolver interface be located Key: MAILBOX-156 URL: https://issues.apache.org/jira/browse/MAILBOX-156 Project: James Mailbox Issue Type: Task Components: api Reporter: Jochen Gazda Assignee: Norman Maurer Currently the GroupMembershipResolver is located within org.apache.james.mailbox.MailboxACLResolver. Please move it to an appropriate place or leave it where it is now. Then remove the FIXME tag. -- 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
[jira] [Created] (MAILBOX-157) Review the ACL persistence in MaildirFolder
Review the ACL persistence in MaildirFolder --- Key: MAILBOX-157 URL: https://issues.apache.org/jira/browse/MAILBOX-157 Project: James Mailbox Issue Type: Task Components: maildir mailbox Reporter: Jochen Gazda Assignee: Norman Maurer There are two FIXMEs in org.apache.james.mailbox.maildir.MaildirFolder. Further the ACL persistence should be tested. -- 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
[jira] [Created] (MAILBOX-158) Find out if a mailbox owner is a group through the namespace of the mailbox
Find out if a mailbox owner is a group through the namespace of the mailbox --- Key: MAILBOX-158 URL: https://issues.apache.org/jira/browse/MAILBOX-158 Project: James Mailbox Issue Type: Improvement Components: store Reporter: Jochen Gazda Assignee: Norman Maurer Patch follows. -- 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
[jira] [Updated] (MAILBOX-158) Find out if a mailbox owner is a group through the namespace of the mailbox
[ https://issues.apache.org/jira/browse/MAILBOX-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated MAILBOX-158: - Attachment: MAILBOX-158-patch.txt Removes two FIXMEs. Is necessary so that user names and group names do not clash. Apply on apache-james-mailbox-store project. Find out if a mailbox owner is a group through the namespace of the mailbox --- Key: MAILBOX-158 URL: https://issues.apache.org/jira/browse/MAILBOX-158 Project: James Mailbox Issue Type: Improvement Components: store Reporter: Jochen Gazda Assignee: Norman Maurer Attachments: MAILBOX-158-patch.txt Patch follows. -- 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
[jira] [Commented] (IMAP-351) ACL Support
[ https://issues.apache.org/jira/browse/IMAP-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13201538#comment-13201538 ] Jochen Gazda commented on IMAP-351: --- Thanks for committing, Norman. I noticed there is an author tag which includes a name like Peter Who is he ? That is my real name. Should I sign up and confess under that name once again? ACL Support --- Key: IMAP-351 URL: https://issues.apache.org/jira/browse/IMAP-351 Project: JAMES Imap Issue Type: New Feature Components: JCR Mailbox, JPA Mailbox, Mailbox, Maildir Mailbox, Parser, Processor, Protocol Affects Versions: 0.3 Reporter: Jochen Gazda Labels: ACL, IMAP Fix For: 0.3 Attachments: IMAP-GETACL.txt, ImapGetACLTest.java Original Estimate: 672h Remaining Estimate: 672h Support for RFC 4314 IMAP4 Access Control List (ACL) Extension -- 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
[jira] [Created] (IMAP-354) Move all CharsetUtil.encodeModifiedUTF7 invocations to ImapResponseComposer
Move all CharsetUtil.encodeModifiedUTF7 invocations to ImapResponseComposer --- Key: IMAP-354 URL: https://issues.apache.org/jira/browse/IMAP-354 Project: JAMES Imap Issue Type: Improvement Reporter: Jochen Gazda Priority: Minor All CharsetUtil.encodeModifiedUTF7 invocations should be moved to org.apache.james.imap.encode.ImapResponseComposer analogically to org.apache.james.imap.decode.ImapRequestLineReader.mailbox() -- 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
Re: ACL Support - cont. from server-user
Norman, I have created https://issues.apache.org/jira/browse/IMAP-351 on 2012-01-18. When may I expect that it will be reviewed? Best, Gazda On Wed, Jan 18, 2012 at 2:29 PM, Norman Maurer norman.mau...@googlemail.com wrote: Wow very nice work. I would be more then happy to include it into our code-base. Please open a jira and attach the patch there (don't forget to check the ASL2 box). Once its there I will pull the changes in. Thanks, Norman 2012/1/17 Jochen Gazda gazdahims...@gmail.com: Gentlemen, could please somebody have a look at the attached patch? It should be applied against current directory. I hope have created it properly. I have never done it before. The patch adds very basic support for GETACL command. A small javamail based demo program is also attached. us...@dom1.com with password 1234 needs to be created before ImapGetACLTest is run. Within my workspace the following tests failed or were skipped for taking too long to finish, whereby I cannot say if it was due to my changes: james-server-smtpserver apache-james-mailbox-hbase james-server-queue-activemq What needs to be done: (1) I have put some FIXMEs and TODOs in the patch where somebody experienced should please have a look. (2) ACL getter and setter stubs should be filled in Mailbox implementations. New tests should be added for those getters and setters. Due to the fact that there is no ACL persistence support in the mailbox implementations, the only ACLs that are effective at the moment are the global ACLs in org.apache.james.mailbox.UnionMailboxACLResolver. The default values for these global ACLs are: (a) full rights for mailbox owner if the mailbox owner is a user and (b) full except for a (administration) rights if the mailbox is a group. I guess this is roughly how it worked before my patch. (3) Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes, see RFC 4314 section 5.2. (4) Enforce rights required to perform different IMAP4rev1 Commands in IMAP processors, see RFC 4314 section 4. Write tests. (5) MailboxACLUpdated event should be fired and litstened to. Best, Gazda - 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 - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (IMAP-351) ACL Support
ACL Support --- Key: IMAP-351 URL: https://issues.apache.org/jira/browse/IMAP-351 Project: JAMES Imap Issue Type: New Feature Components: JCR Mailbox, JPA Mailbox, Mailbox, Maildir Mailbox, Parser, Processor, Protocol Affects Versions: 0.3 Reporter: Jochen Gazda Fix For: 0.3 Support for RFC 4314 IMAP4 Access Control List (ACL) Extension -- 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
[jira] [Updated] (IMAP-351) ACL Support
[ https://issues.apache.org/jira/browse/IMAP-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Gazda updated IMAP-351: -- Attachment: ImapGetACLTest.java IMAP-GETACL.txt The patch adds very basic support for GETACL command. A small javamail based demo program is also attached. us...@dom1.com with password 1234 needs to be created before ImapGetACLTest is run. Within my workspace the following tests failed or were skipped for taking too long to finish, whereby I cannot say if it was due to my changes: james-server-smtpserver apache-james-mailbox-hbase james-server-queue-activemq What needs to be done: (1) I have put some FIXMEs and TODOs in the patch where somebody experienced should please have a look. (2) ACL getter and setter stubs should be filled in Mailbox implementations. New tests should be added for those getters and setters. Due to the fact that there is no ACL persistence support in the mailbox implementations, the only ACLs that are effective at the moment are the global ACLs in org.apache.james.mailbox.UnionMailboxACLResolver. The default values for these global ACLs are: (a) full rights for mailbox owner if the mailbox owner is a user and (b) full except for a (administration) rights if the mailbox is a group. I guess this is roughly how it worked before my patch. (3) Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes, see RFC 4314 section 5.2. (4) Enforce rights required to perform different IMAP4rev1 Commands in IMAP processors, see RFC 4314 section 4. Write tests. (5) MailboxACLUpdated event should be fired and litstened to. ACL Support --- Key: IMAP-351 URL: https://issues.apache.org/jira/browse/IMAP-351 Project: JAMES Imap Issue Type: New Feature Components: JCR Mailbox, JPA Mailbox, Mailbox, Maildir Mailbox, Parser, Processor, Protocol Affects Versions: 0.3 Reporter: Jochen Gazda Labels: ACL, IMAP Fix For: 0.3 Attachments: IMAP-GETACL.txt, ImapGetACLTest.java Original Estimate: 672h Remaining Estimate: 672h Support for RFC 4314 IMAP4 Access Control List (ACL) Extension -- 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
Re: How to build James from trunk
Thanks for the tips, Eric and Ioan. Maven seems to work as expected now. Gazda On Thu, Jan 12, 2012 at 8:13 AM, Ioan Eugen Stan stan.ieu...@gmail.com wrote: Pe 11.01.2012 21:40, Eric Charles a scris: Hi Jochen, Your settings.xml seems ok. 'mvn package' (or even compile) from a toplevel should take the snapshots from your sources even if not installed. I usually invoke 'mvn clean install' in case of weird behaviour. Can you now compile? Thx, Eric Also, sometimes, it helps to delete all downloaded files from your maven local repository. -- Ioan Eugen Stan http://ieugen.blogspot.com - 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
Re: ACL Support - cont. from server-user
Thank you for your advice, Eric, but my efforts with protocols-imap are pointless now, as protocols-imap was removed from the svn repo yesterday. Gazda On Wed, Jan 11, 2012 at 8:38 PM, Eric Charles e...@apache.org wrote: Hi Jochen, You will need to replace all references in sever and app pom to apache-james-server-imap-* with groupIdorg.apache.james.protocols/groupId artifactIdprotocols-imap/artifactId As said earlier, this copy of imap is less stable. Thx, Eric On 10/01/12 19:52, Jochen Gazda wrote: Eric, On Fri, Jan 6, 2012 at 6:34 PM, Eric Charlese...@apache.org wrote: As a side note, we are moving IMAP code from https://svn.apache.org/repos/asf/james/imap/trunk/ to https://svn.apache.org/repos/asf/james/protocols/trunk/imap/ I would be better that you code in the latter. I have coded with /james/protocols/trunk/imap/ and I would like run my code with James. How can I do it? The default build results in James with /james/imap/trunk/. How can I replace it? Thanks, Gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles - 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
Re: [jira] [Resolved] (PROTOCOLS-87) Add support for APOP
Norman, org.apache.james.pop3server.core.PassCmdHandler is not compilable since your r1230560 org.apache.james.pop3server.core.PassCmdHandler.auth(POP3Session, String) is not compatible with org.apache.james.protocols.pop3.core.AbstractPassCmdHandler.auth(POP3Session, String, String) Best Gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
How to build James from trunk
Gentlemen,
I am quite new to maven, so maybe I am missing something obvious.
Issuing
cd james/current
svn update
mvn package -DskipTests -e
has brought a compilation error in james-server-protocols-library
saying that org.apache.james.protocols.api.logger.Logger could not be
resolved. From maven's output it seemed that
protocols.version=1.6-beta3 was used instead of 1.6.0-RC2-SNAPSHOT. I
could not find any occurence of 1.6-beta3 in my workspace. I have
concluded that maven's local repository ~/.m2/repository must somehow
cause the inclusion of improper protocols.version. I have created a
dedicated settings-james.xml for james builds with a new empty local
repository:
?xml version=1.0 encoding=UTF-8?
settings xmlns=http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
localRepository${user.home}/.m2/repository-james/localRepository
/settings
After having done that there came another james error:
[ERROR] The project org.apache.james:apache-james:3.0-beta4-SNAPSHOT
(/home/gazda/james/current/app/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact
org.apache.james:james-server:pom:3.0-beta4-SNAPSHOT and
'parent.relativePath' points at no local POM @ line 26, column 13
I have changed the parent relativePath from empty to ../server/pom.xml
and voila... The build fails on postage. As I do not need postage I
have simply commented it out in current.pom.xml. After that the build
succeeds.
The question is: what kind of care does /current/app/pom.xml need?
(a) I should set the parent.relativePath somewhere in my environment or
(b) parent.relativePath should be fixed in /current/app/pom.xml
Thanks
Gazda
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
Re: How to build James from trunk
On Tue, Jan 10, 2012 at 10:20 AM, Ioan Eugen Stan stan.ieu...@gmail.com wrote:
Pe 10.01.2012 11:14, Jochen Gazda a scris:
Gentlemen,
I am quite new to maven, so maybe I am missing something obvious.
Issuing
cd james/current
svn update
mvn package -DskipTests -e
has brought a compilation error in james-server-protocols-library
saying that org.apache.james.protocols.api.logger.Logger could not be
resolved. From maven's output it seemed that
protocols.version=1.6-beta3 was used instead of 1.6.0-RC2-SNAPSHOT. I
could not find any occurence of 1.6-beta3 in my workspace. I have
concluded that maven's local repository ~/.m2/repository must somehow
cause the inclusion of improper protocols.version. I have created a
dedicated settings-james.xml for james builds with a new empty local
repository:
?xml version=1.0 encoding=UTF-8?
settings xmlns=http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
localRepository${user.home}/.m2/repository-james/localRepository
/settings
After having done that there came another james error:
[ERROR] The project org.apache.james:apache-james:3.0-beta4-SNAPSHOT
(/home/gazda/james/current/app/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact
org.apache.james:james-server:pom:3.0-beta4-SNAPSHOT and
'parent.relativePath' points at no local POM @ line 26, column 13
I have changed the parent relativePath from empty to ../server/pom.xml
and voila... The build fails on postage. As I do not need postage I
have simply commented it out in current.pom.xml. After that the build
succeeds.
The question is: what kind of care does /current/app/pom.xml need?
(a) I should set the parent.relativePath somewhere in my environment or
(b) parent.relativePath should be fixed in /current/app/pom.xml
Thanks
Gazda
From what I know the code in trunk is going through some refactoring right
now so it may not be buildable. I suggest you take a tag release instead of
trunk.
Someone correct me if I'm wrong.
Thank for your prompt reply, Ioan.
Could please somebody utter a forecast when will the trunk be worth
building again?
Best,
Gazda
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
Re: How to build James from trunk
Eric,
this is my ~/.m2/settings-james.xml which I always specify as mvn
command option:
?xml version=1.0 encoding=UTF-8?
settings xmlns=http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
localRepository${user.home}/.m2/repository-james/localRepository
/settings
Is there something weird in it?
Performing mvn package does not touch the local repository, right?
Maybe that is why I get the errors. I probably must run mvn install
instead.
Thanks
Gazda
On Tue, Jan 10, 2012 at 7:21 PM, Eric Charles e...@apache.org wrote:
Hi there,
Trunk is buildable (at least here and on hudson
https://builds.apache.org/job/james-server-trunk/2530/).
Try to force a clean via 'mvn clean install' if it really does not work
Maybe there is something weird in your maven settings.xml?
Thx,
Eric
On 10/01/12 11:04, Jochen Gazda wrote:
On Tue, Jan 10, 2012 at 10:20 AM, Ioan Eugen Stanstan.ieu...@gmail.com
wrote:
Pe 10.01.2012 11:14, Jochen Gazda a scris:
Gentlemen,
I am quite new to maven, so maybe I am missing something obvious.
Issuing
cd james/current
svn update
mvn package -DskipTests -e
has brought a compilation error in james-server-protocols-library
saying that org.apache.james.protocols.api.logger.Logger could not be
resolved. From maven's output it seemed that
protocols.version=1.6-beta3 was used instead of 1.6.0-RC2-SNAPSHOT. I
could not find any occurence of 1.6-beta3 in my workspace. I have
concluded that maven's local repository ~/.m2/repository must somehow
cause the inclusion of improper protocols.version. I have created a
dedicated settings-james.xml for james builds with a new empty local
repository:
?xml version=1.0 encoding=UTF-8?
settings xmlns=http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
localRepository${user.home}/.m2/repository-james/localRepository
/settings
After having done that there came another james error:
[ERROR] The project org.apache.james:apache-james:3.0-beta4-SNAPSHOT
(/home/gazda/james/current/app/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact
org.apache.james:james-server:pom:3.0-beta4-SNAPSHOT and
'parent.relativePath' points at no local POM @ line 26, column 13
I have changed the parent relativePath from empty to ../server/pom.xml
and voila... The build fails on postage. As I do not need postage I
have simply commented it out in current.pom.xml. After that the build
succeeds.
The question is: what kind of care does /current/app/pom.xml need?
(a) I should set the parent.relativePath somewhere in my environment or
(b) parent.relativePath should be fixed in /current/app/pom.xml
Thanks
Gazda
From what I know the code in trunk is going through some refactoring
right
now so it may not be buildable. I suggest you take a tag release instead
of
trunk.
Someone correct me if I'm wrong.
Thank for your prompt reply, Ioan.
Could please somebody utter a forecast when will the trunk be worth
building again?
Best,
Gazda
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
--
eric | http://about.echarles.net | @echarles
-
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
Re: ACL Support - cont. from server-user
Eric, On Fri, Jan 6, 2012 at 6:34 PM, Eric Charles e...@apache.org wrote: As a side note, we are moving IMAP code from https://svn.apache.org/repos/asf/james/imap/trunk/ to https://svn.apache.org/repos/asf/james/protocols/trunk/imap/ I would be better that you code in the latter. I have coded with /james/protocols/trunk/imap/ and I would like run my code with James. How can I do it? The default build results in James with /james/imap/trunk/. How can I replace it? Thanks, Gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
ACL Support - cont. from server-user
Gentlemen,
Please read and comment.
I have started to implement the ACL support. In the very first phase I
would like to
- add support for IMAP GETACL command and
- add support for storing ACL at least for one storage backend.
During this first phase I would like to learn how to do things in a
James-compiliant way so that I will be able to implement other ACL
commands later.
1. A new interface org.apache.james.mailbox.MailboxACL and default
implementation org.apache.james.mailbox.store.SimpleMailboxACL
Stores an ACL applicable to a mailbox. Inspired by RFC4314 IMAP4
Access Control List (ACL) Extension.
Note: An ACL class that could serve our purpose exists in
com.sun.mail.imap. We will not stick to a proprietary API, will we?
2. MailboxACL usage:
org.apache.james.mailbox.store.mail.model.MailboxId and
implementations will be extended to store the related ACL:
MailboxACL getACL();
void setACL(MailboxACL acl);
This is probably OK.
3. MailboxACL usage: org.apache.james.mailbox.MessageManager.MetaData
will be extended to offer a read access to the ACL of the related
mailbox. This was approved by Norman Maurer.
MailboxACL getACL();
4. MailboxACL usage: Under org.apache.james.imap ACL-related requests,
decoders, responses, encoders and processors will use MailboxACL.
It is probably OK as there is a lot of org.apache.james.mailbox.*
usage under org.apache.james.imap.
5. MailboxACL instantiation: Clearly, there will be (at least) two
places where MailboxACL will be instantiated:
i. In Mailbox implementations when reading ACLs from their backends
ii. In org.apache.james.imap decoders when parsing the ACL related
IMAP requests.
At the moment I have hardcoded a constructor of my default
implementation on both places. I am asking myself if some kind of
factory pattern should be used instead.
6. How to access an ACL stored in a mailbox backend from a subclass of
org.apache.james.imap.processor.AbstractMailboxProcessor:
At the moment I have this code to prepare a response for GETACL IMAP command:
MessageManager messageManager =
getMailboxManager().getMailbox(buildFullPath(session, mailboxName),
mailboxSession);
MetaData metaData = messageManager.getMetaData(false,
mailboxSession, FetchGroup.NO_COUNT);
I have not tested it yet, but principally, it should work. I only
wonder at two things with that code:
i. org.apache.james.mailbox.MailboxManager.getMailbox(MailboxPath,
MailboxSession)
It returns a MessageManager rather than a Mailbox. Should it not
rather be called getMessageManager?
ii. org.apache.james.mailbox.MessageManager.getMetaData(boolean,
MailboxSession, FetchGroup)
Javadoc says Gets current meta data for the mailbox. Why is
this method in MessageManager and not in MailboxManager?
7. What and in which order should the GetACLProcessor say after
sending the ACL response?
i. Should it send also unsolicitedResponses?
ii. unsolicitedResponses should be sent before or after okComplete?
iii. on MailboxException, we send no() and I wonder what should its
HumanReadableText say?
iv. is the no() sufficient for all exceptions? What if somebody is
asking for ACL of a folder which
(a) does not exist or
(b) cannot be looked up by the current user?
Isn't taggedBad more suitable for (a) and/or (b)?
Here is what I have now:
@Override
protected void doProcess(GetACLRequest message, ImapSession
session, String tag, ImapCommand command, Responder responder) {
final MailboxManager mailboxManager = getMailboxManager();
final MailboxSession mailboxSession =
ImapSessionUtils.getMailboxSession(session);
try {
String mailboxName = message.getMailboxName();
MessageManager messageManager =
mailboxManager.getMailbox(buildFullPath(session, mailboxName),
mailboxSession);
MetaData metaData = messageManager.getMetaData(false,
mailboxSession, FetchGroup.NO_COUNT);
ACLResponse aclResponse = new ACLResponse(mailboxName,
metaData.getACL());
responder.respond(aclResponse);
okComplete(command, tag, responder);
//FIXME should we send unsolicited responses here?
//unsolicitedResponses(session, responder, false);
} catch (MailboxException e) {
// FIXME: be more specific in the human readable text.
no(command, tag, responder,
HumanReadableText.GENERIC_FAILURE_DURING_PROCESSING);
}
}
8. Interpretation of ACLs:
To have ACL stored on every mailbox is far from being able to tell if
the given user can perform the given operation for the given
mailbox(es when copying/moving).
A new service responsible for resolving of ACLs is necessary. I
propose to call it MailboxACLResolver.
In which package should it be placed? Also in org.apache.james.mailbox?
Probably every single operation between IMAP and mailbox stores should
pass through this service. Where in the code should such a permission
Re: ACL Support - cont. from server-user
Norman, 8. Interpretation of ACLs: To have ACL stored on every mailbox is far from being able to tell if the given user can perform the given operation for the given mailbox(es when copying/moving). A new service responsible for resolving of ACLs is necessary. I propose to call it MailboxACLResolver. In which package should it be placed? Also in org.apache.james.mailbox? Probably every single operation between IMAP and mailbox stores should pass through this service. Where in the code should such a permission enforcement be placed? How should MailboxACLResolver be instantiated? Yeah mailbox api I think… It should be instanced once and get injected in the constructor. Hmmm... I thought that MailboxACLResolver would offer a method like the following: boolean hasRight(User user, Mailbox mailbox, Right right); But org.apache.james.mailbox.store.mail.model.Mailbox is not visible in in mailbox-store. Should I place MailboxACLResolver to mailbox-store? Or I should rely on org.apache.james.mailbox.MailboxPath rather than Mailbox itself? [MailboxACLResolver] should be instanced once and get injected in the constructor. Which constructor? MessageManager or MailBoxManager or both? Best, Gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: missing svn:ignore on some Eclipse files
Thank you for your promt reaction, Eric. however, after updating the following two are still missing the svn:ignore: /protocols/trunk/imap/.classpath /protocols/trunk/imap/.project Best, Gazda On Tue, Jan 3, 2012 at 7:33 PM, Eric Charles e...@apache.org wrote: Good catch Gazda, We sometimes leave such small stuff to fix to see if you guys follow trunk :) You can svn up, it should be fixed now. Don't hesitate to come back if you like more information on any of the James project. Cheers, Eric On 03/01/12 15:03, Jochen Gazda wrote: Ladies Gentlemen, My Eclipse is showing me changed or unversioned decorations on the following resources, which should IMHO have svn:ignore prop set on them (should they not?): /maven-mpt-plugin/.settings /protocols-imap/.classpath /protocols-imap/.project Best, Gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles - 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
Re: missing svn:ignore on some Eclipse files
Eric, thank you for your effort. Everything is as expected after your r1227116. Best, Gazda On Wed, Jan 4, 2012 at 11:35 AM, Jochen Gazda gazdahims...@gmail.com wrote: Thank you for your promt reaction, Eric. however, after updating the following two are still missing the svn:ignore: /protocols/trunk/imap/.classpath /protocols/trunk/imap/.project Best, Gazda On Tue, Jan 3, 2012 at 7:33 PM, Eric Charles e...@apache.org wrote: Good catch Gazda, We sometimes leave such small stuff to fix to see if you guys follow trunk :) You can svn up, it should be fixed now. Don't hesitate to come back if you like more information on any of the James project. Cheers, Eric On 03/01/12 15:03, Jochen Gazda wrote: Ladies Gentlemen, My Eclipse is showing me changed or unversioned decorations on the following resources, which should IMHO have svn:ignore prop set on them (should they not?): /maven-mpt-plugin/.settings /protocols-imap/.classpath /protocols-imap/.project Best, Gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org -- eric | http://about.echarles.net | @echarles - 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
missing svn:ignore on some Eclipse files
Ladies Gentlemen, My Eclipse is showing me changed or unversioned decorations on the following resources, which should IMHO have svn:ignore prop set on them (should they not?): /maven-mpt-plugin/.settings /protocols-imap/.classpath /protocols-imap/.project Best, Gazda - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
