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 06:24:14 GMT
  OK, we've done a picture of the current situation.

I would like to pick an simple example as strong requirement to unify 
the store/repository (whatever then name is) API across all projects.
In spoolmanager.xml, we define respositoryPath such as db://maildb/spam. 
These repositoryPath are used in mailets,...
Let's say I want to develop a mailet that under certain conditions 
stores the mail in a folder (let's say "spam" folder) of the user.
If the mailbox is for example JCR, I have no standard way to define the 
folder path in the james-server "repository" syntax. Or I must invent 
one... (jcr://...? or a more generic one mailbox:///? because I don't 
want to change spoolmanager.xml if spring-beans.xml changes)

If both are linked, we have clear conventions to implement.
And we can always release any project when we want.

This is why I think we should link in a way or another the james-server 
repository and the imap store. Not only on syntax extension, but also on 
implementing classes.



On 6/09/2010 07:49, Norman Maurer wrote:
> 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

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

View raw message