james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: What's in a store?
Date Mon, 06 Sep 2010 05:49:05 GMT
Comments inline..


2010/9/6 Eric Charles <eric@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<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 :)
>>
>> ---------------------------------------------------------------------

Bye,
Norman

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


Mime
View raw message