james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject Re: What's in a store?
Date Mon, 06 Sep 2010 04:34:23 GMT
  Hi Norman,

pop3server has store in its pom, but does not really need it. I will 
carefully test before commit the changes.

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.

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?
2.- must server repository infra be simplified and merged with the imap 
3.- must we leave that separated?

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.



On 5/09/2010 20:11, Norman Maurer wrote:
> Hi Eric,
> comments inside..
> 2010/9/5 Eric Charles<eric@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 :)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message