james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject What's in a store?
Date Sun, 05 Sep 2010 15:44:36 GMT
  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.

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.

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...



PS: I didn't even talked of the AbstractFileRepository

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message