Comments inline..
2010/9/6 Eric Charles <e...@apache.org>: > Hi Norman, > > pop3server has store in its pom, but does not really need it. I will > carefully test before commit the changes. Should be safe to remove it then.. > > JPAUser is accessed in JPAUsersRepository (instanciated via the LocalUsers > repository) while JPAMailbox is managed in JPAMailboMapper is accessed via > JPAMailboxMapper. JPAUsersRepository and JPAMailboxMapper are created in > completely different ways. Ok, I think the "mapper stuff" is just in imap to make implementing different Mailbox stores easy. So its ok to have it work different. > > I see that james-server has a whole infrastructure around "repository". Imap > has not that infrastructure and rely on implementing different stores in > different projects. The questions are: > 1.- must imap go to server repository infra? Not sure.. > 2.- must server repository infra be simplified and merged with the imap > approach? -1 No > 3.- must we leave that separated? Have them seperate allow to have a independend release cycle. Well I know imap had no release yet but I hope to get it done this week. > > btw, even in james-server, all persistence does not go the same way: > domainlist does not work completely with repository. > If you take the JDBCDomainList, it needs a repositoryPath which is > db://maildb/domain (I don't see directly the relation with the > persistence.xml for the mailbox, and however, it stores in the same > database...). However, if you take the JPADomainList, it does not need any > "repository", because it's using the persistence.xml. > I mean, the repository principle has some exceptions in james-server. > The RepositoryPath stuff is from the good old days. With this concept its possible to use more then one db. Like db://maildb/domain (db = maildb, table = domain) and db://maildb2/domain (db= maildb2, table = domain). The whole concept is a "left-over" from using excalibur and avalon. To be honest I don't care if we remove it at all, one db should be enough... > Tks, > > Eric > > > On 5/09/2010 20:11, Norman Maurer wrote: >> >> Hi Eric, >> >> comments inside.. >> >> 2010/9/5 Eric Charles<e...@apache.org>: >>> >>> Hi All, >>> >>> The store project has the mappers and imports some classes of mailbox >>> (mailboxmanager,...), so 'store depends on mailbox'. >>> >>> To access some mailbox/subscription, you need to use the maibox project >>> (example: imap-processor depends on mailbox, and imapProcessor bean is >>> injected with mailboxmanager/subscriptionManager). So far, so good. >>> >>> mailbox is the interface to the mailboxes,...": I had a quick look at the >>> pop3server dependencies and saw that it was depending on store. I didn't >>> find that logical, removed it, and it was still compiling. Logical... >>> Thinking in "what depends on what" helps much. >> >> pop3server should not depend on store and only depend on mailbox. If >> its not the case its a bug.. >> >> >>> However, the other '"domain classes" (user, virutalusertable, domain in >>> the >>> sense 'domain.tld') are accessed in a all different way. This comes >>> probably >>> from the history (before using imap projects, server used its own storage >>> system which has been kept). In spring-beans.xml, you've got: >>> - users-store: org.apache.james.container.spring.SpringUsersStore class >>> being injected via @Resource >>> - virtualusertable-store : >>> org.apache.james.container.spring.SpringVirtualUserTableStore being >>> injected >>> via @Resource >>> - domainlist: XML/JDBC/JPADomainList being injected via @Resource >>> >>> I see there 3 differents access to the persisted domain classes (Mailbox, >>> Message, Subscription, Domain, User, VirtualUserTable): >>> >>> 1. Injection of mailbox project (MailboxManager, MessageManager, >>> SubscriptionManger,...) beans >>> 2. Injection of spring-common project (SpringUsersStore, >>> SpringVirtualUserTableStore) beans >>> 3. Injection of core-function project (XML/JDBC/JPADomainList) beans >>> >>> If you persist everything in a database, accesses for JPAUser is done >>> completely differently compared to the JPAMailbox for example. >>> >> Could you explain whats the dfference ? >> >>> Coming to the point, should we: >>> >>> 1. Continue to live with heterogeneous access the persistence layer? >>> 2. Have uniform access to persistence for all services and all >>> domains? In this case, a store project would be a good name, but >>> is >>> already taken... we could always rename the existing one... >>> >>> WDYT? >>> >>> Eric >>> >>> PS: I didn't even talked of the AbstractFileRepository >>> >>> >> The whole *Store stuff is just a pita (james-server).. The idea with >> its was that you can configure for example different UserRepositories >> and just lookup the right one via the UsersStore. So its really >> flexible. However the loading of the classes + injecting the right >> dependencies is really complicated with this. I'm open to new ideas to >> make it more easy :) >> >> --------------------------------------------------------------------- Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
